DOCUMENT RESUME 



ED 294 514 



HE 021 563 



TITLE 

INSTITUTION 
PUB DATE 
NOTE 



AVAILABLE FROM 



PUB TYPE 

EDRS PRICE 
DESCRIPTORS 



IDENTIFIERS 



Leveraging Information Technology. Track VII: 
Outstanding Applications. 
CAUSE, Boulder, Colo. 
88 

93p.; In: Leveraging Information Technology. 
Proceedings of the CAUSE National Conference (Tarpon 
Springs, FL, December 1-4, 1987); see HE 021 556. 
CAUSE Exchange Library, 737 Twenty-Ninth Street, 
Boulder, CO 80303 (Individual papers available for 
cost of reproduction). 
Speeches/Conference Papers (150) 

MF01/PC04 Plus Postage. 

Administrative Policy; Budgeting; ^College 
Administration; Databases; Higher Education; 
* Information Technology; * Innovation; Local Area 
Networks; ^Management Information Systems; 
Microcomputers; Online Systems; Private Colleges; 
Scheduling; School Registration; State Universities; 
Telephone Communications Systems; Travel; Two Tear 
Colleges 

Baylor University TX; *CAUSE National Conference; 
Cornell University NT; Distributive Computing; 
Louisiana State University; School Identification 
Cards; University of Michigan; Virginia Polytechnic 
Inst and State Univ; Waubonsee Community College IL; 
Winthrop College SC 



ABSTRACT 

Eight papers from the 1987 CAUSE conference's Track 
VII, Outstanding Applications, are presented. They include: Image 
Databases in the University" (Reid Kaplan and Gordon Mathieson); 
''Using Information Technology for Travel Management at the University 
of Michigan" (Robert E. Russell and John C. Hufziger); "On-Lina 
Access to University Policies and Procedures: An Award-Winning 
Administrative Information System" (Bruce B. Harper and Wayland H. 
Winstead); "Affordable Touch-Tone Phone Student Registration and 
Self-Registration without Mortgaging Tour College" (Paul G. Bosse and 
Louis A. Herman); "CUDA: An Adventure in Distributed Computing" 
(Louise Marie Schulden); "The Four-Tear ID" (Roth Aymond); "The 
Development of a Successful Microcomputer Network (deration: Winthrop 
College's Novell NetWare LANs" (William J. Moressi and C. Brown 
McFadden); and "Changing Administrative Database Philosophy: Network 
to Relational" (Becky King). (LB) 



******************** ****************i:************ie*******ie* 

* Reproductions supplied by EDRS are the best that can be made * 

* from the original document. * 
*******^********* ****************************************************** 



ERLC 



Leveraging Information 
Technology 

Proceedings of the 
1987 CAUSE National Conference 

TElACKVn: Outstanding AppKcations 

December 1-4, 1987 
Iimisbrook Resort 

Tarpon Springs, Florida 

"PERMISSION TO REPRODUCE THIS 
MATERIAL HAS BEEN GRAN'.C? tJY 

TO THE EDUCATIONAL RESOURCES 
INFORMATION CENTER (ERIC)/' 



Copyright© 1988 CAUSE 



U.S. DEPARTMENT OF EDUCATION 
Otf<e d Educalion*! flesetrch and improvement 

oriQinaiirig »L 
QMmo, Change, have been made to ,mp.ove 

teproduclion qua'ity 

OER> posrtion or policy. 



2 




CAUSE, the Professional Association for Computing and Information Tech- 
nology in Higher Education, helps colleges and imiveraities strengthen and 
improve their computing, cpmmimications, and information services, both 
academic and administrative. The association also helps individual members 
develop as professionals in the field of higher education computing and infor- 
mation technology. 

Formerly known as the College and University Systems Exchange, CAUSE 
was organized as a volunteer association in 1962 and incorporated in 1971 
with twenty-five charter member institutions. In the same year the CAUSE 
National Office opened in Boulder, Colorado, with a professional staff to serve 
the membership. Today the association seives almost 2,000 individuals fi^om 
730 campuses representing nearly 500 colleges and universities, and 31 
sustaining member companies. 

CAUSE provides member institutions with many services to increase the ef- 
fectiveness of their computing environments, including: the Administrative 
Systems Query (ASQ) Service, which provides to members information about 
typical computing practices among peer institutions fi*om a data base of 
member institution profiles; the CAUSE Exchange Library, a clearinghouse 
for documents and systems descriptions made available by members through 
CAUSE; association pubhcations, including a bi-monthly newsletter, CAUSE 
Information^ the professional magazine, CAUSE / EFFECT, and monographs 
and professional papers; workshops and seminars; and the CAUSE National 
Conference. 

We encourage you to use CAUSE to support your own efforts to strengthen 
your institution's management and educational capabilities through the 
effective use of computing and information technology. 
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INTRODUCTION 



As professionals in an always-exciting field, we are constantly facing challenges to blend new infor- 
mation technologies into our institutions. It is important for higher education to develop environ- 
ments that promote the use of information technology for strategic advantages, that allow faculty, 
staff, and students to benefit firom existing technology, and that stimulate the discovery of new 
opportunities. 

The 1987 CAUSE National Conference, with its theme ^Leveraging Information Technology," offered 
the opportunity for us to share, exchange, and learn of new developments in information technology 
to improve and enhance our environments. The CAUSE87 pn^m was designed to allow the fullest 
possible discussion of issues related to these new developments. Seven concurrent tracks with 49 
selected presentations covered important issues in general areas of policy and planning, manage- 
ment, organization, and support services, as well as in the specialized areas of communications, 
hardware/software strat^es, and outstanding applications. 

To expand opportunities for informal interaction, some changes were made in the program schedule. 
CAUSE Constituent Groups met the day before the conference, as they did in 1986, but were given 
opportunities to meet again during the conference. Current Issues Sessions were moved to Thursday 
afternoon to provide some flexibility with time, encourage interactive participation, and extend 
opportunities to continue discussions with colleagues. Vendor workshops were offered for the first 
time this year, the day before the conference. The Wednesday afternoon schedule accommodated 
continued vendor workshops, vendor suite exhibits, and concurrent vendor sessions. 

David P. Eoselle, President of the University of Kentuclgr, set the tone for CAUSE87 with a Wednes- 
day morning opening presentation expressing his conmutment to the value of information technology 
in higher education. John G. Kemeny, past president of Dartmouth Collie and currently Chairman 
of the Board of True BASIC, Inc., spoke during Thursda/s luncheon of new developments in comput- 
ing for classroom learning. The concluding general session, Frida/s Current Issues Forum, offered 
an exchange of philosophies about making optimal use of technologies on our campuses. 

We were extremely fortunate to be at Innisbrook, a resort with outstanding conference facilities and 
great natural beauty (and weather)— a real distillation of the best of Florida. 

Almost 800 people attended CAUSE87. Many of them described the conference, in their evaluation 
forms, as stimulating, informative, and memorable. We hope this publication of the substance of 
CAUSE87 will be a continuing resource, both for conference-goers and for those who will be reading 
about the conference offerings for the first time. 
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IMAGE DATABASES 
IN 

THE UNIVERSITY 
by 

REID KAPLAN 



Presented by 
REID KAPLAN and GORDON MATHIESON 

Management Information Systems 
Yale University 



Historically, computer database systems ha-^e been used only for 
applications that had easily codified and key-entered data elements, 
or a payback great enough to justify complicated encoding and 
processing. Advances in personal computers now make it possible to 
include complex objects or documents in databases inexpensively 
Instead of relying on descriptors alone to convey information about an 
object, we can include an actual picture of it in a database. This 
image can be manipulated, stored, retrieved, and displayed by standard 
database management systems augmented by a few special purpose modules 
and assisted by a graphics board. We have found that there are as 
many administrative applications of image systems as there are 
academic ones. After discussing image system concepts, we will 
describe, and demonstrate, prototype systems from each area. The 
first will be for a Human Resources Department: an image database for 
tracking applications for employment. This document has much 
handwritten information that causes key entry to be prohibitively 
expensive. Also, the paper form itself is hard to find in simply 
indexed filing cabinets. Conversely, electronic images of the 
document can be scanned and retrieved quickly and cheaply. The second 
will be a database of archived color paintings in one of Yale's 
museums. This allows researchers instant access to paintings for 
comparative studies, stylistic analyses, and many other scholarly 
tasks . 
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I • Introduction • 

In the Spring of 1986 it became apparent that essential hardware and 
software components of image processing and image database management 
systems had been created for use with personal computers and were 
inexpensive enough to be cost effective in many applications. Some were 
commercially available and the release of others was imminent. At the 
same time, it was also apparent that this facet of the data processing 
industry had only recently emerged and both the marketplace and the 
technology were chaotic. In essence, there were a number of different 
solutions looking for a problem and key elements of a solution to some 
specific problems did not exist. However, the potential advantages of 
manipulating and managing pictures in the same ways as traditional data 
were so obvious that Management Information Services (MIS) initiated an 
investigation of the technology. The way to do this was to develop 
prototype image databases with off-the-shelf hardware and software. Actual 
experimentation would graphically illuminate the issues involved as no 
amount of speculation or literature searches could. 

From the very beginning we had a clear idea of the heart of any 
microcomputer-based image system, the database management system. It is 
essential that images be managed in the same way, with the same 
flexibility and with the same response to unanticipated demands, as Yale's 
alphanumeric data. It is also essential that image database management 
systems be compatible with those that manage the university's central data 
resources. 

It was also clear that we had to select objects that were visually 
deuianding as well as informationally complex. A simple task would not 
tell us much. We were fortunate to find two organizations that had 
suitable objects, had text databases describing the objects, and had 
enough interest to cooperate with us: the British Art Center (BAG) and the 
Department of American Decorative Arts of the Yale University Art 
Gallery. We created integrated text and and color video image databases 
of a subset of the paintings in the former and of three dimensional silver 
artifacts in the latter. 

In order to investigate scanner technology and pursue the elusive 
grail of the paperless office, we coupled together an easy to use PC 
database management system and an image scanner. The application we chose 
to develop was for the Human Resources Department: a system for tracking 
applications for employment. 

This report describes, in general tei"^ms, what we have learned during 
the course of creating these prototypes and the current status and 
potential applications of this technology. 

II. 1. The structure and content of digital images. 

An image on the monitor screen of a personal computer can be 
considered to be the analogue of a table: a rectangular array of cells 
called picture elements, pixels for short. If the notion of an image as a 
table is extended in one conceptual dimension, the color of each pixel can 
be integrated into an overall image description. Imagine the bits that 
encode the color of the image to be orthogonal to the plane of the image, 
sticking out of it, if you will. We can now talk about ''bit planes-', 
layers of bits in a rectangular array. The larger the size of the code 
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representing the color, the greater is the image's fidelity to the 
original because more discrete colors can be represented. For our 
purposes, we can consider gray -.^•vels of monochrome images to be colors, 
too. 

What is a color that ye may know it? For the purposes of computer 
displays, a color is a number that differs by a single bit from all other 
numbers used in an encoding scheme. That single bit will cause a primary 
color component to be increased or decreased by one quantum or level. In 
the most commonly used additive color model, red, green, and blue are the 
primary components that are varied to produce a final color. Contrary to 
common belief, it is not possible for combinations of three primary colors 
to match all colors, nor must primary colors be red, green and blue. 
However, it turns out that these three match the largest numbers of colors 
and so are most efficient (Sears and Zemansky 196O, 886-888). An example 
will make clear how colors might be encoded. In the scheme used with 
AT&T's Truevison Advanced Raster Graphics Adapter (TARGA) 16, red, green, 
and blue are each represented by a 5 bit number; 00000 00000 00000 is 
black, and 11111 11111 11111 is white. Pure bright red is 11111 00000 
00000; lightest pink is 11111 11110 11110. There are 32 possible levels 
of each primary color and, therefore 32 cubed or 32k colors total. Grays 
are indicated by three identical 5 bit groups. Obviously, if only grays 
were being displayed, the redundancy inherent in this encoding would be 
grossly wasteful of storage. One would choose, therefore, to employ a 
single number to indicate each level. 

How many colors are enough? It depends on what you are trying to do 
and it depends on the interaction of the human eye with the display. It 
has been reported in journals, unfortunately without attribution, that 
psychovisual studies have shown that a human can distinguish between 16 
million different distinct colors but can only identify about 50 different 
gray levels. Our own studies have shown that the ability to distinguish 
between two adjacent colors is dependent on which components are changed. 
It is not only that the eye is most sensitive in the green portion of the 
spectrum, there is also some sort of weighted averaging going on. If a 
majority component of a color is changed by one unit, the result is much 
more apparent than if a low level component is changed. To continue the 
TARGA 16 scheme with the use of decimal equivalents, suppose that the RGB 
components of a color are 31 15 15 *• a tomato red. A change to 3I ik I5 is 
just barely noticeable even though the eye is most sensitive to green. A 
change to 30 15 15 t however, is very noticeable. 

In addition to color content of an image, subject matter makes a 
great difference in perceived image quality. For instance, humans are 
extraordinarily talented at recognizing human faces. Many fewer colors 
are required for a picture of a face to be rated highly. Thus, personnel 
or security applications of image systems can get away with lower 
performance hardware than more general systems. There are also situations 
where a large number of colors is not desirable. In an application where 
the image is schematic and not intended to reflect reality, too many 
colors can be distracting. Standard presentation graphics, maps, or CAD 
images use color for information encoding, by and large. In such 
cases, the image is very confusing if it is shown with more than about I6 
colors. However, if the image is of an actual object or scene, or a 
simulated object is intended to appear real, 32,000 colors might be barely 
adequate . 
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The eye*s ability to discern color variation is not the only reason 
for wanting many colors in a natural image. Color resolution can, to a 
certain extent, create an illusion of high spatial resolution. This is 
why the woefully inadequate color TV specification in this country has not 
sparked viewer rebellion. The way this happens is by an effect called 
antialiasing. We have all seen the stairstep pattern that results at a 
diagonal border between areas of two different colors. It is sometimes 
called "jaggies" and it is an artifact of raster scanning on low 
resolution devices. The technical term for this is aliasing • The 
appearance of aliasing can be mitigated by inserting pixels of 
intermediate colors between the adjoining areas, but it requires that many 
colors be available for smooth transitions to occur. The TARGA boards 
have clearly demonstrated the value of a large number of colors. They are 
nominally 512 x 512 pixels; only l\82 are visible in the vertical 
dimension. This is no better than msny EGA boards on the market, but, 
with 32k to l6m colors available, the images they display are vastly 
superior. Even the new VGA, with 256 colors, displays images that look 
like crude posters in comparison. Antialiasing can work with gray levels, 
too. Another ATW group has developed a system for teleconferencing that 
uses a scanner capable of detecting l6 gray levels. The scanned image is 
d:* splayed on standard EGA boards with a resolution equivalent to 80 dots 
per inch (dpi). This is much below the 300 dpi that has become the 
desktop publishing minimum standard, but the images are much more 
realistic and legible when displayed on the monitor screen with 
anti-aliasing* 

II. 2. Scanning and video image capture. 

There are, at the moment, two primary ways of getting images from the 
real world into a computer: scanning them with a chargt-coupled device 
(CCD) array or capturing a frame from a video camera. The electrical 
signals representing the image are converted to numbers, digitized, by a 
special processor board in a personal computer • 

Scanners are primarily intended for flat objects, but that is a matter 
of the design of the optical subsystem; at least one device has a depth of 
field of several inches. Scanners have the virtues that they are 
inexpensive, optimized for paper handling, and, at the moment, have higher 
spatial resolution than video cameras. They are comparatively slow 
however; scanning a full page takes about l4 seconds. Video cameras are 
more versatile in that they can take pictures of any sort of object or 
scene and the image can be modified during capture. They have highly 
developed color reproduction mechanisms and can operate swiftly; an image 
can be captured in l/^v. of a second. As in photography, lighting and 
color calibration are of crucial importance. 

Image capture is the most expensive and technologically limited step 
in the process. It is expensive because it is labor intensive and because 
cameras with capabilities at or in excess of current broadcast standardij 
do not benefit from the economies of ^scale that consumer electronics lik^ 
personal computers enjoy. It is technologically limited because there 
have been few incentives to develop devices with capabilities beyond the 
current broadcast standards. Nevertheless, it is possible to capture 
images for about the same cost per image as photography because there are 
no consumables and the labor costs in either case swamp the capital costs. 
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II. 3* Image editing and enhancement. 



After digitization, the image is invariably manipulated in some way. 
Even the simplest application will require elimination of distracting 
backgrounds, centering, s^i^ing, rotating, and the like. More complex 
applications will demand the sort of processing that, until now, has been 
used only by television and movie studios. Exampl<5s are color alterations 
and the integration of text and original graphics with the image. 

If the central goal of the application is image analysis or 
enhancement, image manipulation can be extremely involved and the results 
can border on the miraculous. We have seen most of this technology 
exercised on the fascinating pictures sent back from space by the Voyager 
vehicles. It is possible to filter out salt and pepper noise - the 
equivalent of snow on the home TV screen, restore definition, accentuate 
features such as edges, expand the dynamic range of the picture, and so 
forth. Image processing programs that do ail these things are routinely 
available for PC's and cost about as much as 2 to ^ copies of a full 
function word processor. 

II. 4. Image storage and data compression. 

Images are file hogs. In the worst case, a full page, 16 gray level 
image takes around 100k. The smallest half page, k level image we have 
seen is around 23k. Color images take about ^90k for an uncompressed, 32k 
color, 512x512 picture. No single magnetic disk at the DOS limit of 32 mb 
(320 pages) can hold enough images for a practical database. However, 
with the steady improvement of magnetic disks, the emergence of new 
storage devices, and the judicious use of compression techniques, 
practical, useful systems can result. 

At the moment, we are using standard magnetic disks for storage. An 
IBM PC-AT with a 20 mb hard disk and an external cartridge disk drive with 
40 mb immediately accessible, can store about 2^0 full screen color or 
1200 black and white pictures. As the cartridges are removable, the total 
potential size of any database Is infinite. Currently, there are commonly 
available personal computers with 100 to I30 megabyte disks. If history 
is any guide, the capacity of magnetic disks attached to PC's will 
quadruple in capacity and halve in cost per byte in the next three years. 
This means that image databases of 1000 immedieitely accessible color or 
5000 black and white pictures stored on magnetic disks will be commonly 
affordable. In that same time, a new technology should mature. This is 
fortunate as many applications will require larger storage than magnetic 
media can provide. 

Optical disks, capable of storing between 200 mb and 1000 mb on a 
single disk are available now, and will be routinely supported by PC 
system software. They have one important technical limitation; the data 
can only be written once. Thus, they are restricted to applications with 
static databases or enough users to justify creating new disks 
periodically. These devices are called WORM drives and CD ROM. WORM 
stands for Write Once Read Many and CD ROM for Compact Disk Read Only 
Memory. Both use optical technology to achieve an extraordinarily high 
data packing density. A WORM cartridge is written by the physical 
ablation of spots by a high energy laser and read by differential 




reflection of light from those spots. Because writing involves 
irreversible physical changes, an update consists of rewriting the 
affected portions and ignoring the old version. However, the important 
point is that the writing mechanism is included in the drive and the user 
can initiate the writing and rewriting i.ocaliy. A CD, although 
superficially similar in that information is contained iti laser detectable 
pits, must be mastered ap.d pressed in a plant, a complicated and expensive 
process. Moreover, it really is a read only medium. If updating is 
required, a new disk must be mastered and a pressing run initiated. 
Obviously » tnis is cost effective only for static, high volume items. 

How one stores one's images depends on the size of the image 
database. As described earlier, images of moderate quality are quite 
large. However, there are compression techniques that reduce the size of 
image files. Depending on the image content, an image file can be 
compressed to between 60% and 10% of its original size without loss of 
information. Compression techniques can be classified as destructive or 
nondestructive, and the lattv^r can be divided into methods that take 
advantage of an image raster structure and methods that can be applied 
to any type of data. 

Destructive compression techniques are usually applied to an image's 
colors; rarely are images compressed in the spatial domain. The reason is 
that an image's spatial resolution is usually fixed to be that of the 
graphic adapter that will display it. In the simplest case, an image is 
posterized. That can be accomplished simply by truncating or averaging 
the color code. The result looks very much like a poster with large 
regions of single colors bounded by abrupt changes. There are, however, 
smarter schemes that will sample the image and select an optimal reduced 
palette. Some of these schemes operate not on individual pixels but on 
tiles of, say» 16 pixels. There exists a proprietary processor add-in 
board that can do this swiftly in hardware and allows the user to se.lect 
the degree of destruction. Tlie resul\\s for some images are nearly 
indistinguishable from the original. 

Of the nondestructive compression schemes, the simplest is run-length 
encoding. This takes advantage of the fact that an image is sade up of 
lines and often these lines contain sequences, or runs, of identical 
color* SOf an image can be stored as a series of doubles; one number is 
the color of the ran and the other is the number of pixels in the run. It 
turns out that "natural" images, pictures of real ob.^ects, can be 
comprtr^ssed o\)ly about 10% by this technique, although computer produced 
graphics are compressed anywhere from 5OX to S0%. The problem with 
natural -mages is that there are subtle hue differences from pixel to 
pixel. For instance, an image of a white wall actually consists of small 
patches of blues* pinks, and various other unnameable shades. One way 
around this problem is to run-length compress by bit plar.e rather than by 
pixel. Of course, this is possible only with boards that have planar 
encoding schemes. In the CGA, blue is encoded by 0001, green by 0010, and 
the intermediate cyan (blue-green) by 0011. If adjacent pixels in a run 
were made up of theso three colors in alternation, no compression could be 
achieved by considering them as individual pixels. But all three have the 
two hif order planes in common and so could be compressed by about ^0% 
if olanes were collapsed into tv;o doubles. 

.several compression techniques based upon statiscica"^ 
an; t\ge content. The original, and still popular, example of 

5 

12 



these is Huffman encoding (Huffman 1952). A first pass is made through 
the image data to determine the relative frequencies of colors. The most 
common color is encoded with the shortest code. The next most common 
color is encoded by the next longest code, and so on. I'he result is a 
table, called a Huffman map, of original color codes and their optimal new 
encodings. During the second pass through the data the new codes are 
assigned. To decompress the file, the Huffman map is used as a key. This 
is a time consuming process; on a 12 megahertz 80286 machine a 49^k image 
compresses in 12 seconds to 26% of its initial size and decompression 
takes 9 seconds. To increase speed, boards have been developed to perform 
the process in hardware and to eliminate the analysis step. They depend 
on predetermined maps determined by examination of a large number of 
"typical" documents encountered in fax transmissions. This map has been 
dubbed Fax Group 3. It works fairly well if the images conform to Group 3 
statistics, but not all do. Clearly this only applies to gray level 
images . 

II. 5* Image display and output. 

After they are stored, and retrieved for some specific purpose, images 
must be displayed. 

The immediate, and many times, only, display device is a high quality 
color monitor controlled by a display adapter. The monitor is largely a 
passive device; the image is stored and manipulated in the adapter and the 
adapter determines its resolution. The standard PC Color Graphics Adapter 
has 6^0 pixels horizontally and 200 vertically when it is displaying 2 
colors; the IBM EGA is 6^0 x 350 and Extended EGA's and the new VGA are 
640 X kSO with anywhere from k to 256 colors displayable at the same 
time. Except for monochrome document retrieval applications^ this is 
barely adequate resolution. Most uses will require either more colors or 
more pixels. For instance, professional Computer Aided Design (CAD) or 
medical diagnostic images have a typical lower limit of 1024 x 768 pixels 
but they require only I6 to 256 colors. For displaying real -world 
objects, a reasonable device is the TARGA 16 with 512 x 512 x 32768 
colors. For somewhat more money, there is a new generation of adapters 
with programmable resolutions of up to 4k x 4k pixels with up to I6 
million colors. These adapters are equipped with onboard graphic 
processors that make image manipulation quick and easy. Only a short time 
ago, these capacities were available only on mainframe or supermini 
systems that cost an order of magnitude more. 

For comparison, a home TV screen in the United States displays about 
480 rows and about 350 columns. This is not really very good, but it is 
made acceptable by the nearly infinite number of colors displayable in 
each pixel. The all-time champ for combined spatial and color resolution 
is photographic film. A 35 mm. color slide, normally thought of as small, 
contains about 6 million pixels or the equivalent of 2958 rows and 2028 
columns. Moreover, each pixel can contain a nearly infinite range of 
colors. 

The monitors that display images, and perhaps standard text as well, 
are of two sorts: digital RGB and analog RGB. The former is 
sometimes called RGBI, for Red Green Blue Intensity, or TTL for the kind 
of transistor logic that is often used. These monitors are designed to 
display only a few colors (or gray levels); the PC standard CGA displays 
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up to 16. These colors are specified by a four bit code that determines 
which of the 3 colors is on or off and if the electron beam is bright or 
dim (Norton, P. 1985» 71"77)* These monitors can be quite inexpensive 
since so little is expected of them, but the colors of images are hardly 
natural. Having said this, it also must be said that the limitations of 
16 gray levels are much less apparent than the limitations of I6 "real" 
colors. This has to do with the inability of the human eye to discriminate 
between gray levels as well as it does between hues. In addition, the 
kinds of monochrome images that are usually displayed do not have a very 
wide dynamic range. Analog RGB monitors can potentially display an 
infinite number of colors because the amplitude of analog signals is 
infinitely variable. As a practical matter, the number of colors actually 
displayed is limited by the amount of display memory available for color 
information. Multisync or multiscan monitors typically have the ability 
to display analog signals as do multipurpose monitors such as the Sony 
PVM-I27IQ and the new generation of monitors for the IBM PS/2. 

Many applications demand display in other media. Cameras that 
transfer digital images to 35 transparencies exist. Our 
experimentation with them show that they do the job very well. However, 
this type of device, like a high quality TV camera, is best shared by many 
users. It is not likely that a single user could keep it busy or would 
wish to spend the $3000 to $5000 it costs. 

We have experimented with transferring color images to paper via 
special thermal and ink jet printers. This technology is still in a very 
primitive state and the technical problems are formidable. No printer we 
know of is currently a true production device; there are problems keeping 
the printers operating optimally, images take 5 to 10 minutes to print, 
and the colors, especially those produced by thermal transfer, are 
unsaturated. For the present, hard copy devices are best used to produce 
proofs before a final copy on film. Of course, the image may be printed 
in standard ways from the film copy. 

II. 6. Image database management systems. 

Perhaps it is because of our background, but there was never any doubt 
that database management systems (dbms) must be used for images. An 
unorganized collection of images, even if computerized, is like a shoebox 
full of snapshots. Try to find the one of Aunt Bertha at the beach in 
1927. Fortunately, database management systems that integrate images with 
descriptive and categorical text now exist. Unfortunately, there seem to 
be only two sorts: fairly simple but fairly inflexible dbms' tacked on to 
a graphic front end and full function, fixed field, dbms* loosely bolted 
to image capture and display facilities. A common denominator of these 
products seems to be that they were designed in a vacuum with no regard 
for the user. We have tried to influence the design and facilities of 
these programs, but, with one notable exception, we have been largely 
ignored. However, we have great faith in market forces; as soon as the 
demand for image systems makes itself felt, the software houses will come 
to heel. 

The first thing a system designer must realize is that an image can 
reside anywhere; it need not be on the same storage device as the programs 
that manage it or the text data that describe it. Thus, a practical image 
database management system must keep track of the volumes and drives that 
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contain the image files. Most PC dbms products do not now have the 
capability to span volumes or know which drives the volumes are mounted 
on. Nonetheless, it is a problem that has long been solved in principal, 
as mainframe users will instantly realize. 

In addition to physical structural flexibility, an image database must 
have logical structural flexibility. For instance, the capability to have 
more than one image per record is a necessity, although many current PC 
products do not allow this. 

Apart from the need for extreme storage flexibility, image databases 
have the same functional requirements for their management as standard 
databases. An image database schema will be identical to one that 
contains no pictures except that the alphameric fields will be limited to 
a minimal set of descriptors. After all, the image contains most of the 
information in such a database and only those descriptors required for 
retrieval need be entered. Also, the familiar database functions of add, 
update, and delete all have image analogues. These analogues will differ 
on two counts from the ones we are all familiar with: they must cope with 
two-dimensional objects of variable size. 

Addition of images to a database requires complex editing facilities 
and clever linking to text descriptors. In the standard dbms there are 
certain editing functions provided by hardware and software that are 
considered essential when entering text, such as deletion, insertion, 
overstriking of individual characters, and placement of individual 
characters within the field. These are simple because of the orderly, 
linear, left to right, top to bottom structure of western scripts. In 
addition, certain arbitrary but reasonable limitations are placed on the 
amount of text that may be entered. Two dimensional data are much more 
difiicult to handle because of the transformations possible in the plane 
and because there are far fewer conventions that constrain those 
transformations. It is also true that there is a much less clear cut 
dividing line between record entry and record modification. For instance, 
a retailer may wish to provide its dealers with a database of parts for 
inventory and quick access. Each individual image "page" may actually 
consist of parts of several primary images: a picture of the part, text 
attributes such as part number, location in the storage area, and a 
diagram of where the part fits in the assembly. If the user has to first 
paste these up by hand in an art department, there is much less incentive 
to use electronic retrieval as a cost saving measure. An image editor 
should allow individual sub-images to be captured and then modified to 
form the final image ready for retrieval. 

The simplest form of image editing is cropping. Except for certain 
archival applications oriented towards the 8 1/2 x 11 page, it is not 
acceptable to force the inclusion of an entire image as captured. Real 
estate, physical security, and inventory applications come readily to mind 
as requiring cropped images. Cropping is easy to do, is included in almost 
every database product, and, moreover, it has an important technical 
benefit: it saves image memory buffer and disk storage space. 

To be really useful, an editor must include the three two-dimensional 
linear transformations that preserve shape: translation, rotation, and 
scaling. Most image database products have a translation feature, more or 
less well implemented. It allows the composition of a compound document 
and is rather easy to do. Some, but not all, image editors allow 
rotation, and those that do often restrict the angle to 90 degree 
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increnants. It is easy to program in principle, but rotations in other 
than 90 degree increments produce aliasing artifacts that are difficult to 
minimize. In most applications, rotation is used for correcting small 
misalignments in the captured image and, therefore it is essential that 
this function be well implemented. Scaling is the magnification or 
reduction of an image or part of an image. All image database products 
have this capability. Reduction is easy, but magnification is not. The 
reason is that the original was scanned at a absolute resolution floor; 
there is no more detail to see. Therefore, either some sort of 
interpolation and smoothing must be added during magnification or the 
application must be able to tolerate the more obvious appearance of 
pixels . 

A third class of image editing is annotation. This can take two 
forms: locator controlled, or keyboard actuated. This feature has some 
memory overhead due to mouse drivers and/or font storage, although, it is 
easy to do. Some, but not all, products can do this. 

In addition to the simple editing functions discussed above, it is 
possible with some systems to provide full fuLction image editing through 
extensive "paint" packages such as TIPS, PC Paintbrush, or Dr. Halo. This 
can be done if the dbms supplies the user with the names of scanned image 
files. The user can scan, store images temporarily, run a report that 
lists the file name assigned by the dbms with an explanatory or 
identifying field entered by the user, and exit the dbms. Then the user 
invokes the paint package and accesses, edits, and resaves the images. 
This process runs the risk that the user will save the edited image with a 
name unknown to the dbms, but an astute user should be able to maintain 
data integrity with a little effort. 

Updating an image can mean replacing it totally or modifying the 
existing image in some fashion. In both cases it is nearly certain that 
the size of the new image will be different from the old. The database 
manager must allocate and reclaim storage space in an intelligent manner. 
Otherwise, massive inefficiencies can result. If the image is modified by 
the user, the comments made previously about editing apply here. Linkages 
to descriptors must also be maintained. 

Deletion is relatively simple if two principles are applied. First, 
since descriptive f^ata and images may be loosely coupled, it is important 
to ensure deletion of both elements. One can not exist without the 
other. Second, if the storage medium is rewritable, the large space 
occupied by the image should be reclaimed immediately. When images are 
measured in megabytes, waiting to reorganize a file could prove fatal. 

III. Document retrieval: the Employment Application Tracking System. 

Document retrieval is a natural candidate for image database use. It 
is not as flashy as other uses of image technology, but the potential 
payoff is enormous. There are literally forests of paper, that must be 
referred to, in files all over the university. These documents can only be 
filed sequentially by single descriptors so retrieval is tedious and 
expensive. Often these single descriptors are the wrong ones for certain 
important purposes. Worse, many are misfiled and can be lost forever or 
cost an inordinate amount to find. The data on most of these documents 
are not transcribed to a computer database because they are not easily 
codified and key-entered or the payback is not great enough to justify 
complicated encoding and processing. 
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Putting them on microform does not help much. There is a cottage 
industry producing so-called Computer Aided Retrieval programs for 
microform, but the encoding problem still exists and even if you have a 
reference you must still find the microform the document is on. 

A classic example of a document that is difficult to manage is the 
application for employment. It has much handwritten information that 
causes key entry to be prohibitively expensive, especially since the value 
of the document is transitory. In some cases, a photo of the applicant is 
part of the document and must be retrieved too. Currently, applications 
are simply filed by job type and photocopies are mailed to all departments 
that are hiring that category. Employment representatives are assigned to 
deal with broad classes of jobs, upper clerical, for instance. When a 
department requisitions a job search, the rep maintains a local file of 
responding applications and includes all the applications from the central 
file that are possible to find. When the job is filled, all the 
applications are put into the central file for about 6 months, after which 
they are purged. The problems with such a system are obvious. 

Our prototype document retrieval system provides much more capability 
and flexibility while reducing the demands on the employment rep. The 
operator first enters a small set of descriptors about the application in 
a menu driven form displayed on a PC monitor. The application itself is 
then placed on the scanner bed and a function key pressed to scan the 
form. If its appearance is satisfactory, another function key is pressed 
to store the picture of the page. At the same time, the dbms assigns the 
image a unique file name and links it to the descriptor data. 

The system allows for multiple pictures per document, in this case, 
one for each of the four pages of the application. Retrieval is performed 
on the descriptors and has full relational capability. For ad hoc 
retrieval, the operator simply enters criteria into ano:her menu driven 
form on the monitor. Alternatively, a query language can be used for 
complex searches and reports. Those documents that satisfy the criteria 
can be displayed on the monitor by simply pressing still another function 
key. A half page fills the screen, but the entire 8 1/2 x 11 inch page is 
viewable by scrolling using the Page Up and Page Down keys. The user can 
browse back and forth from page to page or cause the page to be printed. 
Alternatively, the pictures of the document can be sent over phone lines 
to the PC of another person for viewing. 

IV. Color video image database: British paintings 

The many objects in Yale's galleries, museums, and collections are 
among the most under-utilized resources of the University. Some may be on 
display, and certain others may be accessible, but a very small fraction 
of Yale's holdings are used for teaching or research. There are a few 
simple reason for this. Many are not catalogued. Even if catalogued, the 
objects* catalogue references have very limited information content. A 
person selecting items for a study collection must still find and examine 
candidate objects for relevance to the objective. In many collections, 
this is not an easy task. It is also true that some desirable, even 
essential, objects may not be available for examination when required. 
Finally, when objects are located and chosen, they must be photographed 
for presentation or examination, for only a few sorts of objects may be 
removed from storage. Photographing is time-consuming, technically 
complex, and expensive. Moreover, a single object may undergo this 
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process several times, making the total cost to the University very large 
indeed. 

Among the Yale institutions addressing these issues, the British Art 
Center has one of the most extensive, informative, and accessible 
catalogues in the Computerized Index of British Art. It contains a total 
of some 42,000 art objects located around the world, of which the Yale 
holdings are an important subset. Textual descriptions of the art are 
managed by a flexible database management system which also directs 
searchers to an entry in an archive of black and white photographs. 
Although this system is a major step forward toward addressing the 
problems of speedy and inexpensive access to a complete information 
source, there are still some very important elements to be added before .tt 
can be used routinely for teaching and research. Pictures of the art are 
obviously the most important. 

A user must be able to perform ad hoc requests for information, 
browsing through the database to find the appropriate items. In order to 
determine the appropriateness of the objects, they must be displayed 
instantaneously for immediate acceptance or rejection. At present, a user 
must search for a quantity of candidate objects and, armed with a lengthy 
report, proceed to the photo-archive proper to search for and locate the 
images. A copy of the black and white prints of those works that are 
suitable is then provided the inquirer. Further cycles of enquiries and 
searches might be necessary to refine the final selection. In addition, 
the product, a black and white print, is not often the medium of choice 
for a teacher. Most often, color transparencies are required for 
classroom display. We have been working with the BAC to investigate how 
we might improve their capabilities in these areas and. additionally, 
develop them so chat the result could be transferable to other 
organizations on campus. MIS has captured images of a small subset of the 
BAC's displayed paintings using a recently developed raster graphics 
adapter in a personal computer. Attached to a video camera, this adapter 
can digitize color images of moderately high spatial and color 
resolution. The images are then stored, currently on magnetic media, and 
displayed on a special monitor also attached to the adapter. The images 
can be manipulated in many ways by image processing software that MIS has 
obtained. MIS was a test site for a version of the database management 
system, that is used for the index, that is able to integrate text and 
these images. In addition, color transparencies and color prints can be 
output on demand. On the basis of this study, we have also determined 
that other Yale organizations need, want, and can use the system; a 
prototype has been developed for the silver collection of the Yale 
University Art Gallery and the Yale Babylonian Collection has applied for 
a grant to create a database of images of their cuneiform tablets. 

V. Summary: Application Areas, Common Requirements, and Common 
Problems . 

We have learned that there are four generic applications for computer 
based image systems: 1. image databases, 2. complex illustrations for 
lectures or publications, 3- creative graphic art, and 4. image analysis 
and enhancement. Of great importance is the fact that, except for perhaps 
the last, there are as many specific applications in the administrative 
areas of the University as in the academic. We have also learned that 
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although one of the four may be a user's primary interest, at least one, 
and most often two, of the other categories will be required to support 
it. This means that multiple or integrated software packages are required 
and that there is an immediate community of interest among all users. 
This also means that the University could effect enormous economies of 
scale by providing centralized image capture facilities and concerted 
purchasing programs. 

The weakest links in the technology are the design of the database 
management systems and the image storage devices. These are only 
engineering problems, however, and are certain to be overcome, perhaps 
within a year. Of greater concern in the application of the technology is 
the acceptance of it by the end user. The people who are likely to 
benefit most from it are precisely those who are least technically adept 
and aware. The sociocultural systems that are entrenched in the private 
university compound this problem. Patience, communication skills, and 
friendly systems are essential tools in an implementer's kit. 

Image systems are affordable. An entire PC based workstation, 
including software, is in the $10,000 to $12,000 area. The expense is in 
the personnel costs for image capture. But, thankfully, this is a 
one-time cost and is more than offset by the savings afforded by swift and 
certain retrieval. The cost of finding a misfiled document has been 
estimated to be between $25 and $50. The cost of paper shuffling is 
mounting. The cost-benefit ratio of wharehousing unused and unseen 
objects is infinite. Can we afford not to use this technology? 
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Over the past several years, colleges and universities have begun to 
develop programs to reduce the cost of travel and improve the level 
of service to their travelers. These programs are in response to 
some significant changes within the travel industry brought about 
by airline deregulation, increased competition among travel 
agencies, and the application of information technology to the travel 
agency's **back office" operation. 

In developing these programs, one of the most important objectives 
is to obtain better information about travel patterns. How often do 
travelers go to a specific destination? When do they go and how 
long do they stay? Is there a significant amount of business with a 
particular hotel chain or car rental firm? The information that is 
needed to answer these and other questions is available in airline 
reservation systems, travel agency accounting systems, corporate 
charge card information systems, and institutional data bases. The 
challenge facing college and university travel managers is to 
effectively utilize information technology as a major component in 
a travel management program. 
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Using Information Technology for Travel Management 

at 

The University of Michigan 

The Emergence of Travel Management at Colleges and Universities 

Over the past several years, a series of events in the travel industry has made it 
advantageous for colleges and imiversities to develop programs to reduce the 
cost of travel and improve the level of service to their travelers. The first 
event was the deregulation of the airline industry, which resulted in increased 
competition between airlines and lower airfares. Lower airfares meant lower 
commissions to travel agents, and, in order to gain a larger market share, travel 
agencies became more aggressive in competing for the business traveler. By 
offering services designed specifically for the business traveler, agencies hoped 
to increase revenue. Computerization of the travel agency was another event 
tl\at provided the opportunity for savings to colleges and universities. While 
airline reservation systems have been in use for many years, it was only 
recently that the back office of the travel agency was fully automated. This 
automation has made it possible for travel agents to provide a wide range of 
management reports to their business travel customers. 

Another trend in the travel industry that is becoming more commonplace in 
colleges and universities is the use of a corporate charge card. There are two 
primary reasons for implementing a corporate card program. First, it can 
provide another means of obtaining valuable information about travel 
patterns to be used in negotiating discounted fares and rates. Reports that are 
commonly available with such programs include expenditures by industry 
(airlines, hotels, etc.), by vendor, and by geographic region. Second^ it reduces or 
eliminates the need for cash travel advances; these funds can then be put to 
more productive use. 

Travel industry experts estimate that savings of up to 40% can be achieved by 
implementing policies and procedures to provide better control over travel 
expenditures. The amount of savings obtained will depend on how liberal ttie 
existing policies are and how restrictive the new policies might be. It will also 
depend on the volume of travel and the particular travel patterns of an 
institution's travelers. Institutions that have a very decentralized travel policy 
can expect minimum savings of 18%-20% in air fare expenditures by 
concentrating their business in a single off-premise, full-service travel agency 
that guarantees to offer the lowest applicable airfare. Savings of 30%-40% or 
more can be obtained if a large percentage of air travel is between a small 
number of city pairs, which would make it possible to negotiate bulk fares 
directly with an air carrier. Savings of 10%-20% in hotel and car rental rates 
can be achieved by negotiating rates based on expected use. 
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Travel Management si The University o£ Michigan 

Within this framework. The University of Michigan implemented a Travel 
Management Program in 1985 designed to reduce travel costs and improve the 
level of service to Universiiry travelers. This program has three major 
components: 

>>• Designated Travel Agents 



>>• University-Sponsored Charge Card 



>>• A Coordinating Office 



In selecting designated agents, the University developed a set of criteria that 
was used to evaluate the ability of a travel agency to provide certain guarantees 
and an appropriate level of service to University travelers. Designated travel 
agents have guaranteed that they will meet the objective of offering travelers 
the best available airfare given the constraints of the traveler's schedule - 
commonly referred to as the lowest logical airfare. Designated agencies were 
also required to utilize a rate desk - which provides an independent review of 
all University reservations to insure that the best fare was obtained. Since 
more than 25,000 airfares change each day, the rate desk not only reviews every 
reservation before it is ticketed, but also regularly reviews tickets and 
reservations until the date of departure. If a fare increase is pending, 
reservations are ticketed. If a fare decrease has occurred for tickets already 
issued, or if clearance is obtained for waitlisting on discounted seats, the tickets 
will be re-issued at the lower airfare. On a monthly basis, each designated 
agency submits a magnetic tape containing billing and sales data. 

The University of Michigan selected American Express to provide corporate 
charge cards to faculty and staff. The no-fee, no-liability program currently has 
over 2,700 cards in distribution. Each month American Express provides 
magnetic tapes that are used for reporting and for controlling cards. 

The Travel Services Office was established to coordinate the Travel 
Management Program. This office serves as a liaison with the designated 
agencies, American Express, and University travelers. In addition, the office 
has the responsibility for negotiating discounted fares and rates with airlines, 
hotels, and car rental firms. A newsletter. Travel Tips, is published 
periodically by the office to keep University travelers abreast of industry 
developments, new corporate agreements, and other travel-related issues. 
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Information Resources for Travel Management 



In ttie mid 1970's, travel agents throughout the country began to install 
computerized reservation systems. Now, according to Business Travel News. 
over 97% of this nation's travel agents are using some type of computerized 
reservation system. Although this market is dominated by American Airlines* 
Sabre system and by United Airlines' Apollo system, there is an emergence of 
several new vendors offering equivalent or enhanced systems. These 
reservation systems enable travel agents to make bookings with most major 
airlines, hotels, and car rental companies. The newest and mosi sophisticated 
systems allow the agent to search for the lowest airfares automatically. 

While the majority of agencies are online with a reservation system, it has 
only been in recent years that agencies have begun to automate their back office 
functions. It is estimated that 41% of the travel agents in the United States are 
currently making use of a partially or fully computerized back office system. 
Many of the back office computer systems encompass several of the agencies* 
office functions. 

Some of the back office systems include: 

accounts receivable, payable, & general ledger functions 
^ business forecasting 

commission tracking 

ticket/itinerary printing 
^ reporting capabilities 
^ passenger profile functions 
^ agency branch communications 
^ word processing 

electronic phone book, calendar, & reminder list 
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Of the above functions, the passenger profile systems and reporting capabilities 
directly affect travel management at the University. Passenger profile systems 
allow the agencies to store a list of preferences submitted by University 
travelers. The profile, which contains the traveler's preferred airline, hotel 
chain, car rental company, seat selection criteria, frequent flier numbers, credit 
card numbers, and other similar information is automatically retrieved when 
the agent books airline tickets, reserves hotel rooms, or reserves rental cars for 
the University traveler. The back office reporting capabilities enable the agents 
to extract a client's travel information captured by the reservation system and 
provide it to the client either in the form of management reports or actual 
booking data on magnetic media. 

In addition to capturing the data at the time of the booking. Travel Services is 
able to obtain data that is captured at the time of billing. American Express, the 
University's current supplier of corporate charge cards, provides Travel 
Services with three monthly reports. The first report is a vendor summary 
report listing the total number of transactions and dollar volume spent at each 
vendor. This report is first broken down by the type of establishment, i.e. 
airlines, lodging, auto rental, etc., and then by individual vendor name. The 
second report is a geographic vendor summary listing the same information as 
the first, but is instead broken down by state and city, and then by type of 
establishment and individual vendor. The last report lists all airline tickets 
purchased with the corporate charge card. This report includes the billing 
price, the name of the airline, and the origin and destination on the ticket. 
American Express gives the University the option to receive these reports 
printed on a hardcopy, or to receive the data files these reports are derived 
from on a magnetic tape. American Express also allows their corporate clients 
to sign on to the American Express computer system and run these reports 
online or create their own queries and reports. 

Each month, American Express supplies the University with a magnetic tape 
containing a data record for each existing University corporate cardholder and 
for any newly opened accounts. This tape is used to automatically update the 
corporate cardholder data file maintained by Travel Services. In this way. 
Travel Services is able to keep accurate records of any accounts that have been 
added, suspended, or cancelled. 

The final information resources accessed by Travel Services are the 
University's faculty/staff database and travel voucher history data file. The 
faculty/ staff database is used to verify employment data and produce mailing 
labels for mass mailings by Travel Services. The travel voucher history file is 
used to retrieve the staff identification numbers of all employees who have 
submitted travel expense reports. This was the method used for contacting the 
faculty and staff who do the majority of traveling at the University. 
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All of these resources - computerized reservation systems, travel agency back 
office systems, corporate charge card data systems, and University data systems - 
create various opportunities in which the Travel Services' management is able 
to analyze the University's travel patterns and gather data that can be used to 
negotiate discounted fares and rates. 



Systems for Travel Management 

In order for the University to reduce travel costs and increase the level of 
service for its travelers, it became necessary for Travel Services to develop a 
system in which travel expenditures could be captured and andyzed in a more 
accurate and efficient method. When the Travel Management Program began 
at The University of Michigan, designated travel agents provided the 
University with hard copy reports. Although the reports were adequate in 
supplying information on the distribution of business between the travel 
agents, it was necessary to be able to look at the University's travel 
expenditures as a whole. Therefore, on a monthly basis, a clerk was required to 
manually consolidate the seven sets of agent reports into one set of summary 
reports. This was a very time consuming task. In addition to the large 
amounts of time spent on the manual manipulation of data. Travel Services 
was limited to a specific set of reports the travel agents were providing. 

Based on the experiences gained in the first year of the program, new contracts 
were negofiated with the designated agents that required data be reported on 
magnetic media. Travel Services now receives two data files from each of the 
designated travel agents. One data file contains information regarding each of 
the airline tickets issued to University travelers. The other file contains data 
concerning all hotel bookings and car rentals made through the agent. These 
two files are downloaded from the agent's system to magnetic tape or floppy 
diskette. The files are then loaded onto Travel Services' computer system and 
run through a program which creates a master air file and a master hotel/car 
file. Since the seven designated agents use either American Airlin«;5' Sabre 
reservation system or United Airlines' Apollo reservation system, a program 
to merge the unlike data file formats was developed. 

Once the data is loaded onto the system, the travel coordinator has the ability to 
run several pre-programmed reports. Some of the reports include the 
following: air travel expenditures by cost center, destination analysis summary 
report, airline summary report, hotel booking summary report, rental car 
summary report, and minority vendor summary report. The system allows 
the user to either print these reports or display them directly on the 
workstation. 
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These data files contain all information pertaining to each booking, so the 
reports that may be generated can be quite detailed. One report that was created 
listed all round trips from Detroit to Washington D.C. and the number of 
nights stayed in Washington D.C. hotels. This information was used in 
negotiating discounts with hotels. In another example, a report listing the 
number and dollar volume of domestic and international flights was 
generated. These are just a few of the types of reports that are now available to 
Travel Services. 

In addition to the travel agency report system being used by Travel Services, 
there is a corporate cardholder management system. This system is used to 
keep track of all current accounts, pending applications, and cancelled accouni>. 
Each cardholder record contains several pieces of information: campus address 
and telephone number^ cost center and organization code numbers, American 
Express account number, and preferred travel agencies. In the agreement with 
American Express, the University is required to notify all cardholders who are 
thirty days delinquent in their pa}Tnent. This is accomplished by loading a tape 
produced by American Express at the end of each billing cycle and running a 
program that prints a dunning notice for each delinquent cardholder. The 
cardholder file is also used to produce mailing labels for the rev/sletter 
published by Travel Services and for any correspondence relating io one of the 
designated fravel agents. 

At this time, the vendor summary management reports received from 
American Express are in a hard copy format. A system is under development 
that will allow the University to receive the source data for these reports on 
magnetic tape. When completed. Travel Services will have the ability to 
generate its own reports and maintain a history of the vendor summary data 
on disk. Plans are also being made to allow online communications between 
the University and American Express. With messaging capabilities, routine 
requests could be sent electronically rather than having to wait until the 
University's assigned analyst at American Express can be contacted by phone. 



Conclusion 

Information technology has played a major roJe not only in the 
computerization of the travel industry, but also in the ability of colleges and 
universities to improve their control over travel expenditures. However, the 
benefits of improved control over travel are not just tangible savings. An 
institution that can demonstrate it has taken steps to reduce travel costs may 
have an advantage in seeking federal and state funding, research grants, and 
other sources of support. In addition, an institution and its travelers will 
benefit from the increased level of service tha'; can be obtained. 
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On-line Access to University Policies and Procedures: 
An Award-Winning Administrative Information System 
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Abstract 

As one component of a university-wide move toward the electronic ofUce, 
Virginia Tech has implemented an on-line Administrative Information System. 
The system makes available to the university community, in a cost-effective 
manner, policies, procedures, and general management information in an elec- 
tronic Fact Book. The information system is centrally maintained and has elim- 
inated the need for every office on campus to keep paper copies of the 
Administrative Handbook and other policy manuals. The system has been in use 
for more than a year and won an honorable mention award from NACIJBO for 
its cost savings. 

This paper provides I) a brief history of the development of the system, 2) a 
discussion of the design issues that were identified and addressed during imple- 
mentation and testing, 3) an analysis of usage statistics during the first 16 months 
of operation, and 4) a demonstration of the system. 
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Introduction 



The Administrative Information System (A IS) at Virginia 'lech replaced a traditional systems 
and procedures manual by taking advantage of the university's significant computing and 
communications resources. The new system, which has been in operation for 16 months, was 
designed to resolve audit comments regarding the timely availability of current administrative 
policies and procedures. Though developed outside of the university's normal administrative 
data processing environment, the AIS was also viewed as an extension of the administration's 
commitment to office automation. 

This paper provides a brief overview of the development of the AIS, the necessary conditions 
of its successful implementation, the design issues raised and resolved during development, and 
usage statistics for the first full year of operation. 

Prerequisites 

The development of AIS would not have been contemplated had there not been support of ex- 
tensive ofilce automation through universal departmental access to the university's IBM 3090 
computer. Development of the AIS was also predicated on both a strong commitment to office 
automation by the entire executive administration and a high level of acceptance of office au- 
tomation by staff and faculty. The level of acceptance among staff was considered to be espe- 
cially critical since clerical and secretarial staff were typically more directly involved with 
administrative procedures than faculty. The administration was committed from the outset to 
an on-line system. This commitment was evidenced by the fact that the decision to implement 
AIS was taken without any cost/benefit analysis. In large measure, these factors have contrib- 
uted to the positive acceptance of the AIS. In the absence of these factors, the system probably 
would not have been successfully implemented. 

Progenitors 

While the university's primary information systems were based on IMS, which had a long his- 
tory of user training and security control, by 1985 the university had already begun to imple- 
ment administrative applications under CMS. Almost all of these applications had been 
developed by departments outside of the normal administrative data processing areas. 

Like most systems, the AIS had several progenitors that infiuenced both the decision to imple- 
ment an on-line system and the system's design. In 1982 a prototype system was developed by 
the Computing Center to display the Faculty Handbook at a user's terminal. This system dis- 
played simple text files by selecting the appropriate section from a ''point and push" table of 
contents menu. The system represented a proof of concept prototype but it was never devel- 
oped beyond the prototype stage. In addition to this system, the availability of on-line IIRLP 
under CMS and Computing Center News items offered under a customized CMS nitLP menu 
prompted development of other systems that influenced the design and implementation of the 
AIS. 

Independently, Institutional Research and Planning Analysis (IRPA) developed and imple- 
mented an Electronic Fact Book. Based on the CMS IIBLP facility, this system provided on-line 
access to standard reports available in print in the University Fact Rook. The Electronic Fact 
Book displayed simple text files from a series of "point and push" menus that mimicked the look 
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and feel of the basic CMS UHLP Tacilily, This system was developed, tested, and installed by 
IRPA during 1984 and operated as an independent application until it was incorporated into the 
MS, After introduction of the Electronic Fact Book, the Admissions Office installed the Ad- 
missions Information System that made weekly admissions summaries available on-line, 'fhis 
system was also based on the CMS IIIiLP facility and offered an enhanced system that moni- 
tored user access in order to evaluate system usage. 

A number of other departments also offered on-line "systems" that permitted users to view text 
files containing their standard operating policies and procedures. Like the Standard Operating 
Procedures offered by Sponsored Programs, these displays frequently amounted to little more 
than a listing file that the user could view with standard CMS commands such as XliDIT or 
BROWSn. 

All of these systems required a user to link to a CMS mini-disk and execute a command; to es- 
tablish the link in the PROFILH liXHC and remember the appropriate command; or to create 
a custom exec file that linked to a mini-disk and executed the appropriate command. Only 
those systems based on the CMS IIIiLP facility offered a consistent and familiar "look and 
feel." 

There were several progenitors of AIS that set precedents for on-line access to administrative 
information. These systems infiuenced the administration's objectives for the AIS and its design 
criteria. These progenitors also anticipated some of the problems with on-line access to ad- 
ministrative information under CMS that have yet to be resolved. 

Getting Started 

One of the initial difficulties encountered in the development of the AIS was the lack of an ap- 
propriate "home" for the system. Administrative data processing at Virginia Tech has been 
decentralized for many years. As a consequence, no single administrative department had a 
clear responsibility for the entire system. While it was clearly recognized that the Vice President 
for Administration and Operations had the responsibility for the Administrative Handbook, his 
office had no systems development or programming support. In addition, few administrative 
departments had developed or wanted to develop systems uixlcr CMS, since their primary ex- 
perience was in IMS. 

Under the direction of the Vice President for Administration and Operations, each department 
was trained in basic DCF/GML tags and assigned the responsibility of preparing a source doc- 
ument that would be incorporated into a single Policy Digest. The original intent was to pro- 
vide access to the Policy Digest under CMS and to make it available as a monolithic printed 
reference. Based on its experience in developing the electronic Fact Book, staff in IRPA were 
assigned the task of re«;earching design alternatives, developing the display system and super- 
vising its implementation. 

Afler initial review of the development of the policy and procedure documents, IRPA staff 
identified a critical need for an editor to provide technical writing assistance and to supervise 
the markup of each document By January of 1986, an editor was hired and the development 
plan completed. The development plan called for initial sy.stem testing on .luly 1, 1986 with full 
implementation the following September. 

In common with most of its progenitors, the AIS system was largely developed outside of the 
normal data processing departments. It was not until July of 1987 that the AIS system was 
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formally assigned a permanent stafT and placed under the control of the Office of University 
Services. 



Design Issues 

Given the decision to replace traditional systems and procedures manuals with an on-line sys- 
tem, several design issues were identified. These issues evolved as the system was designed and 
were not part of the decision to implement an on-line system. 

Single-Source Files 

One of the earliest decisions was to design a system that utilized a single-source file to produce 
both on-line files, supplemental printed versions of the policies, and typcsct-quality text where 
necessary. This decision reflected a recognition of the resource requirements to maintain mul- 
tiple files and a desire to avoid errors and omissions in several file versions. DCF/GML (IBM's 
SCRIPT) was selected as the basic text programming language. Basic printed documents were 
to be provided on the 3800 page printing system. In addition, IBM's 4250 printer provided the 
capability to produce professional-quality typeset text where this was desired. The system was 
succcssfiilly developed using the single-source document concept. 

Display Text Files 

The decision to use a single-source document in DCI7(5ML dictated a design of the on-line 
display system based on the storage and retrieval of electronic page images. Sections of each 
document were stored as text files under CMS and the AIS software was designed to select the 
appropriate text file based upon the system menu and use input. Virginia Tech's Systems De- 
velopment department provided a basic Display Management System panel, which was used as 
the AIS main menu, 'fhis was the only part of the AIS developed by Tech's data processing 
professionals. Primary displays in the AIS were based on IBM's XIIDIT full-screen editor with 
customized edit profiles that limit the commands available to the user. 

This design decision led to a large number of files, over 1400 at this writing. However, the al- 
gorithm to create the display files from a single Script source file and the bisic display algorithm 
was quite simple. By keeping the mechanics of the display system simple, we were able to focus 
our efforts on the readability of the basic documents and the consi.stency of text markup fi"om 
one document to the next. 

Responsibilities 

liach department issuing policy was assigned the responsibility for its own document and was 
asked to prepare the initial source file. The AIS editor was assigned the tasks of editing the 
department's original material and developing a consistent markup style for all documents. The 
initial objective was to ensure that each document was written at the 10th grade reading level 
and satisfied generally accepted standards for technical Hnglish. Our intent in attempting to 
achieve the 10th grade reading level was to make the reader's task as simple as possible. Wc felt 
that the on-line display posed enough challenges without expecting the reader to comprehend 
text written at higher reading levels. We believe that this decision had a significant impact on 
user acceptance of the on-line display. 
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These responsibilities were established early in the development process and have worked well. 
Since a consistent markup style for all documents proved to be an essential element in the A IS 
system, we have been successful in achieving this goal in almost all of the documents available 
on-line. Improved readability was not one of the administration's original objectives for the 
A IS, but it has emerged as one of the better unintended benefits. While we have not yet 
achieved the targeted reading level in all documents, we have made significant progress. Most 
of the documents available under the AIS are reasonably close to the targeted lOth grade 
reading level. We have encountered some resistance to lowering the reading level, especially in 
documents such as the Faculty Handbook, It has also proven to be difilcult to achieve a con- 
sistent text markup in documents such as the Faculty Handbook. Where resistance has been 
encountered, the AIS Hditor has yielded to practical realities and merely suggested less cum- 
bersome wording and more consistent text markup. 

Printing 

An initial design objective was to minimize the amount of printing done through the AIS. One 
of the primary objectives of an on-line application was the ability to update policies and pro- 
cedures without the delays normally associated with systems and procedures manuals. It was 
readily apparent that one of the possible drawbacks to this approach was the possible existence 
of out-of-date printed documents. The traditional systems and procedures manuals remedy this 
problem by collecting all of the out-of-date material as verification of appropriate updates to 
the manual. This approach was clearly not feasible for an on-line system. To date we have not 
experienced problems with out-of-date policies and procedures, but we do not have sufficient 
experience to determine if this will continue to be the case. 

After some review, it was decided to support three levels of printing. Mrst, draft printed copies 
of the contents of each display file would be provided using the XPRINT command under 
XHDIT. The draft print facility can be invoked from a PF key while viewing any of the text 
displays in the AIS. A second level of printed distribution is provided in which full copies of 
each document may be printed from a "point and push" menu. The basics of this display were 
borrowed from the Computing Center's Documentation System (DOCS) and the user interface 
improved so it was similar to the Table of Contents menus in the AIS. These documents, which 
are stored in an MVS library, are printed on IBM's 3800 Page Printing System and delivered to 
the user's output distribution box. Delivery can usually be expected with one hour of a print 
request, though the user can control print priority, which determines both delivery time and 
printing cost. A third level of printing involves the production of camera-ready copy that can 
be used to print large numbers of distribution copies. An example of this type of printing is the 
Traffic Rules and Regulations brochure, which the university produces each year and distributes 
to students, faculty, and staff. With the installation of IBM's 4250 printer, the university's 
ability to provide high-quality camera-ready copy has been significantly improved. 

While we have not monitored draft printing, we have maintained statistics on the number of 
documents printed under the AIS. Over the past 16 months, we have printed on average about 
128 documents per month from the AIS. The total number of documents a* ailable for printing 
on the 3800 printer from the AIS has grown from 16 when the system was first installed to 30 
documents at the time this paper was written. We have provided camera-ready copy for only 
one publication, 'FrafTic Rules and Regulations. It appears that the availability of printed copies 
on the 3800 page printer has reduced the demand for more traditionally printed documents. It 
may well be that the next revision of the Faculty Handbook will not be provided in any form 
other than that available on the 3800. 
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Off-campus users 



As a major research university with a traditional land-grant mission, Virginia Tech has depart- 
ments, ofT-campus instructional centers and Agricultural Research Hxperiment Stations 
throughout Virginia. For these remote departments, an on-line system has not proven satis- 
factory. The problems we have encountered are largely due to the relatively high cost of tele- 
communications services and the spotty quality of communications service available over the 
state's wide area telephone service. For off-campus departments, AIS did not provide a satis- 
factory means of documenting administrative policies and procedures. For these departments, 
the university periodically prints updated policies and procedures and ships the documents to 
off-campus users. Other universities considering the development of a similar on-line system 
would be well advised to consider the issue of ofT-campus access during the initial stages of 
system planning. 

CMS or PROFS? 

At Virginia Tech, the user community has evolved into two groups; those who use PROFS as 
the predominant application and those who use CMS. Many of the most sophisticated users 
had a significant commitment to CMS long before the university's formal commitment to office 
automation and the concomitant installation of the PROF^S system. These sophisticated users 
made infrequent use of PROFS and preferred the native CMS environment. On the other hand, 
there were large numbers of users who knew virtually nothing about computing other than the 
facilities provided in PROFS. Unfortunately the look and feel of these environments differed 
considerably. 

It was not considered feasible for AIS to support both of these conventions and one of the most 
difficult initial design decisions required the selection of one sot of conventions. The PROFS 
conventions were selected because it was felt that the least-experienced users would less diffi- 
culty learning how to use a system based on PROFS conventions. Many of the least experi- 
enced users were clerks and secretaries who were expected to be the system's most frequent 
users. The initial design decision was to make AIS available from one of the PROI\S menus 
and to provide a seamless transition from PROFS to the AIS. Consistency with PROI'S con- 
ventions was, however, not maintained in the "point and push" selection of items from the Ta- 
ble of Contents menus. The overall system design would probably have been improved by 
maintaining strict consistency with either CMS or PROFS conventions. The issue of "look and 
feel" was, however, not limited to the AIS system alone. 

Wow many user interfaces? 

The PROFS interface decision reflected part of a larger question raised by the proliferation of 
CMS administrative applications. How many user interfaces were to be permitted? In effect, 
what was the total amount of user training/learning required to function in automated ofTlcc 
environment? This issue has not yet been resolved at Virginia Tech. ('MS-based administrative 
applications have continued to proliferate. At this time we have not developed a formal policy 
regarding the conventions these systems should use nor have we attempted to coordinate secu- 
rity or electronic signature controls in CMS administrative systems. 

Other institutions considering the development of on-line administrative applications should 
give serious consideration to this issue. In theory it should be easier to decide upon a consistent 
"look and feel" and to develop applications to this standard. The establishment of a consistent 
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"look and feci" standard should also minimize the amount of time user's spend learning to use 
administrative applications. Over time, the absence of a consistent standard at Virginia Tech 
may limit the acceptance of on-line CMS administrative applications. 

Security 

Surprisingly, security was not an issue in the development of the AIS. iTom the outset, the 
intent was to foster universal access on the part of faculty, staff and students. Any user may 
access the system without special authorization and view university policies and procedures or 
print a copy of a document. Security precautions were limited to specific XltDIT profiles that 
do not file user changes to the policies displayed on the screen. To date we have had no prob- 
lems with mixed student, faculty and stafT access. 

Wow much information to display? 

Despite our efibrts to keep things simple, we encountered typical design issues that had a big 
impact on the novice user. Among these were decisions on how much information was to be 
contained in each of the display files. We found that one- or two-paragraph display files oflen 
presented information out of context. This led either to multiple user selections from the menu 
in an attempt to gain the context for a particular policy, or to misunderstanding of the policy 
or procedure due to a lack of context, or to complete user frustration evidenced by immediate 
tennination of the session. On the other hand, we found that providing too much text made it 
difilcult for users to find what they needed to know quickly, thus obviating one of the advan- 
tages of an on-line system. We settled on major subheadings (e.g., section 1.1) as an appropri- 
ate compromise, but this decision required considerable care in developing a consistent style 
among documents prepared by many departments. In retrospect, we could have saved consid- 
erable time by identifying and resolving this issue before we began the preparation of the initial 
source documents. We could then have trained each department in the development of policy 
and procedure documents under a consistent style. Institutions contemplating similar on-line 
policy displays could learn from our experience. 

Emphasis and organization 

Rmphasis and organization also proved to be a markup issues that required consideration in 
light of on-line video display. Many of the documents originally had underscores for emphasis, 
but on a CRT display, underscores took a full line (approx 5%) of the display. We also found 
that text justified to both the right and lefl margins was more difficult to read. Wc settled on 
CAPS for emphasis based on capital letters in the on-line display and ragged right justification. 
We also found that it was important to eliminate the blank lines produced by IBM SCRIP'f at 
the end of some of the display files, and that the inclusion of positive top and bottom of file 
indicators helped users to maintain their orientation in the file. 

Index 

We also found that an Index was extremely helpful in finding the appropriate section of a doc- 
ument in the on-line display. The basic GML Index tag, however, provided page references 
which were useless as an index to the on-line display. We solved the problem by writing a 
REXX EXKC that converted page references into section references (e.g., 1.1). Section refer- 
ences have provided a convenient Index for on-line users. The Indices would also be more 
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hclprul if wc had developed a consistent policy regarding index references at the outset. Since 
each department was responsible for its own document(s), the use of keywords or index refer- 
ences varied from one document to another. The documents in the A IS would be easier to use 
if we had established a consistent policy regarding index references and trained each department 
to implement this standard. While the administration had originally envisioned a single, 
monolithic document with a single comprehensive index, the A IS system abandoned that con- 
cept early in the development process. A monolithic document proved to be unmanageable 
since minor revisions to one policy impacted the entire document. We have attempted to pro- 
vide a reasonable index to each document, but have not provided a master, comprehensive index 
for all documents. 

Absence of Forms 

The AIS could not display exact images of many of the administrative forms used on the cam- 
pus. Most systems and procedures manuals have numerous copies of institutional forms that 
can be referenced in the manual. With the obvious technical limitations of a CRT display, this 
was not possible under AIS. While this represents a significant shortcoming when compared 
to traditional systems and procedures manuals, we have not had major problems with this as 
of this time. Our Rmployee Relations Department runs training programs that cover each of 
the major administrative procedures and our Internal Audit Department has not taken excep- 
tion to the absence of exact replicas of these forms in AIS. 

Archives 

One direct benefit of AIS has been the implementation of historical archives of institutional 
policies and policy changes. Heretofore, the university had no central summary of policy or 
procedure changes. The AIS display contains a Revision Status section for each document. 
I)etailed notes are provided in this section on any changes that have been made to the docu- 
ment. The system archives also contain complete copies of each document that preserves an 
historical record of policy changes. 

System Usage Statistics 

To determine if the system was being used and to provide departments with information to de- 
partments about usage of their sections, an enhancement was added to the system that monitors 
usage. For the past 16 months, each time a user has viewed a section or has printed a complete 
document, the usage monitor has extracted the user*s ID, the identifier of the policy being 
viewed or printed, along the date and time. This information has been monitored routinely to 
gauge the system's effectiveness. Since the implementation of usage monitoring, we have been 
able to track usage by department as well as individual user. 

The accompanying tables illustrate system usage over the last 16 months. During a typical 
week, over 100 individual users have accessed the AIS. Total system usage has averaged over 
200 calls per week. During this time over 2000 documents have been printed from the AIS 
Print-a-Document menu. System usage varies with academic sessions and holidays, but this 
variation is typical of most administrative systems and overall computer usage as well. To date 
the administration has been satisfied with overall usage statistics. 
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Virginia Polytechnic Institute and State University Administrative Information System 

Weekly System Usage Since Startup 
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Virginia Polytechnic Institute and State University Administrative Information System 
Print-A-Document Requests, July 1986 to October 1987 
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Synergy 



The MS system began life as the "Policy Digest" since its original intent was to provide policies 
and procedures. Its mission was, however, soon expanded to include the HIectronic I-act Book, 
Admissions Information, Presidential Policy Memoranda, Cjovernance System Commission and 
Committee Memberships, Governance System Minutes, and Summaries of Space Allocations, 
These systems have remained a part of the AIS while other systems have been developed using 
similar user interfaces. 

Within months of its implementation, AIS contained lists of surplus chemicals available free 
from the Safety Department and chemicals available in the Chemistry Department Storeroom, 
These were soon followed by a catalog of Central Stores supplies and equipment that featured 
on-line order preparation, (On-line orders were not developed due to internal control and secu- 
rity considerations raised by our Internal Audit Department.) These systems have been segre- 
gated into stand-alone applications. 

Summary 

While AIS began as a system available from a PROFS menu, the increased number of CMS 
administrative applications soon led to the installation of the INFO System, which was devel- 
oped by the Computing Center, Since the INFO System was based on CMS conventions, its 
introduction led to the demise of the seamless transition from PROF'S into the AIS. Depart- 
ments have continued to develop administrative applications under CMS and the number of 
distinct user interfaces has continued to grow. This growth has been reflected in the increased 
numbers of applications and sub-menus available from INFO. 

The system received a sixth-place cost-reduction incentive award in 1987 from the National 
Association of College and University Business Officers (NACUBO), Despite this award, the 
AIS must still be considered an experimental system. It was developed in a typical "skunk 
v/orks" manner, incorporating elements from existing systems and working out design issues and 
problems as they arose. It was during its development a low budget system and it continues to 
be a low budget operation at this time. The system has been successful in achieving the major 
objectives established by the administration. How the system will fare over the long run and 
the eventual fate of other administrative applications under CMS will have to await the verdict 
of stair and faculty users in an increasingly complex automated ofTice environment. 
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This paper describes one institution's 
innovative approach to providing inexpen- 
sive registration methods without over- 
extending a college's financial situation. 
Both touch-tone phone registration and 
self-registration systems are reviewed. 
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AFFORDABLE TOUCH-TONE PHONE STUDENT REGISTRATION AND 
SELF-REGISTRATION WITHOUT MORTGAGING YOUR COLLEGE 



BACKGROUND 

Waubonsee Community College, a two-year public institution of higher learning, was 
established in July, 1966 and is located approximately 50 miles west of Chicago, Illinois. 
The area served by Waubonsee Community College encompasses approximately 600 
square miles and includes twelve public school districts. The College's name, meaning 
"early dawn" or "early day", was chosen to honor a Pottawatomi Indian chief who lived in 
the Fox River Valley during the 1800's. 

Waubonsee officially opened its doors for classes on September 11, 1967, to an initial 
enrollment of 1,603 students of whom 403 were full-time and 1,200 were part-time. The 
College has continued its growth pattern and the fall of 1986 showed 5,304 students en- 
rolled of which 1,057 were full-time. 

A 183-acre tract of land located approximately two miles north of Sugar Grove on Illinois 
Route 47 was chosen and a permanent campus constructed. Seven buildings were 
constructed with the eighth building, the new College Center, being completed in the fall 
of 1982. In 1983, planning was begun for a major extension center in Aurora, where 
approximately one-half of the population of the district reside. A three-story building, 
which formerly housed Carson, Pirie, Scott and Company (retail clothing store), was 
renovated for educational purposes. 



TOUCH-TONE TELEPHONE REGISTRATION SYSTEM 

Waubonsee Community College is utilizing a touch-tone telephone registration system 
that was implemented in May, 1987. Student registration calls are routed through a 
modem card in an IBM/AT compatible, which in turn communicates with the on-line 
student system (HP-3000). Each modem card can handle up to four telephone lines. 
Waubonsee is utilizing five lines. Four modem cards can be inserted into an IBM/AT. 
The modem cards and PC software used in Waubonsee's touch-tone 
registration system was provided by Computer Communications Specialists, Inc. (CCS) of 
Norcross, Georgia. See figure A for CCS costs. 

Any student who has ever attended Waubonsee previously has the opportunity to use the 
phone registration system. The system can handle registrations for multiple semesters at 
one time utilizing a four-digit coding system for each class. Touch-tone registration is 
available 24 hours a day, 7 days a week, allowing for a short back-up time every night. 
Students must call from a touch-tone phone which has touch-tone service. 
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Full-time and part-time students can register for both credit and/or non-credit courses. 
The system has the ability to check any of the following: required applications, required 
assessment testing, registration overloads, minimum age requirements, prerequisite 
authorizations for specialized courses, outstanding financial obligations, parking tickets, or 
library fines. The system can be modified to fit Waubonsee's changing needs. New 
program changes and the corresponding voice messages can be modified in-house without 
the additional cost and time of using an outside service. The College was able to utilize 
existing audio visual and PC equipment. 

Waubonsee first offered phone registration service to the public in May 1987 for the Sum- 
mer semester. One percent of students enrolled for summer used the system. Three per- 
cent of the students enrolled for the Fall 1987 semester have used the phone system to 
register. It is anticipated that the percentage of students using the system will continue to 
grow. Surveys indicate that the students have enjoyed the convenience of registering by 
phone, whether at home or work and intend to use the system again. About one-half of 
the students would like to use the system to pay their tuidon by credit card. 

Students can add a course, drop a course, check for open courses, clieck their schedule, or 
check their current balance due by phone. They are only charged a user fee if they add or 
drop courses. The system and script are both user-friendly and provide self-help menus 
and instructions. 

TIME LINE 



July 1986 Initial inquiry about CCS registration system 

August 1986 D^'qn of Information Systems visits CCS in Norcross,Georgia 

September 1986 Presentation to adminstrative staff 



September 1986 Presentation to Board of Trustees 
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December 1986 


Final contract signed 


January 1987 


Arrival of equipment 


January 1987 


HP3G00 interfaced with CCS equipment 


February 1987 


Script 


March 1987 


Testing 


April 1987 


Promotional advertisement 


May 1987 


Phone system made available to public 


June 1987 


Final round of surveys 


October 1987 


Second round of surveys 
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Overall Hardware and Software Conflguration 



Overall hardware for the college includes: 

3 HP-3000 computers with 142 ports 

1 IBM-4361 with 32 ports 
+ 200 Personal Computers 

2 386 computers 

1 Dytel Automated Attendant System 

1 AT&T Dimension/400 Phone System 

1 AT Dytel Voice Mail System 

The major philosophy of Waubonsee's Computing Plan is to maintain a distributive com- 
puting network of multiple, small, powerful, user friendly computers that support and com- 
municate with each other. 

Waubonsee has invested in 4th generation software that has allowed the development of 
its own administrative applications. The Hewlett Packard Data Base Management System 
and the Cognos Powerhouse software has made Waubonsee many times more productive. 
In our type of environment, it is usually wiser to purchase software that makes us more 
productive in application development, rather than purchasing turn-key application pack- 
ages. 

The (3) HP-3000 computers have (142) ports and support over (90) personal computers. 
Files can be up and down loaded from the PC's to the HP-3000's, as well as doing normal 
on-line and batch activities. The HP-3000's all run the same operating system and are 
fully compatible to each other. They back each other up in case of an emergency. We 
have never had to switch over to another HP-3000; but, if needed, this is part of our 
Problem Management Procedure. One of the HP-3000's is located in another building, 
the Learning Resource Center. This HP-3000 primarily serves the Library System with 
on-line circulation and cataloging. But, it also serves as a "hot site" for the other two HP- 
3000's, and is an important part of our Disaster Recovery Plan. The second HP-3000 is 
used for all administrative production computing. The third HP-3000 is utilized for 
academic computing, a high school network, and administrative systems development. 
The IBM-4361 is primarily an academic computer. See figure B for configuration over- 
view. 

Waubonsee's computing philosophy is to use personal computers whenever possible, utiliz- 
ing the larger computers only when necessary. Word processing is an example of this 
philosophy. We have word processing on the HP-3000's, but almost all word processing 
occurs on the PC's. 



Touch Tone Registration Hardware & Software Configuration 

Waubonsee's Touch Tone Registration System follows the computing philosophy in that 
PC's are utilized with the larger computers only when necessary. Outside telephone calls 
come into a Dytel Automated Attendant System. The Dytel provides (5) phone extension 
lines into (2) CCS modem cards in an IBM/AT personal computer. See figure C. 
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The IBM/AT: 



1. answers the (5) phone lines. 

2. speaks the desired messages under program control back thru the phone line. 

3. receives input from the student's touch tone phone. 

4. sends records to the HP-3000 Student Data Base. 

5. receives records from the HP-3000 Student Data Base. 

6. digitizes voice messages through a microphone and stores it on the 30MB hard disk. 

The HP-3000 takes a request record and processes it against the Student Data Base, and 
sends back the record to the IBM/AT. The HP-3000 thinks it is simply communicating 
with a terminal. All communication is asynchronous and ASCII. 

The following is a brief description of adding a new message to the system: 

1. Record the ..ssired phrase using a microphone into the AT using the RECORD 
program. Example file name PK046.DAT which is our welcome message phrase. 

2. Update the file name PK046.DAT into the phrase file named WAUBONSEE.DIR 

3. Run the program VLIB. This inputs WAUBONSEE.DIR and outputs a combined 
phrase file called WAUBONSEE.LIB 

4. Run the program MESSAGE. This defines a message that can be made up of one or 
more phrases. A unique message number is assigned. 

5. Update the COMMAND.DAT file to include the new message number. 

Tie COMMAND.DAT file provides the logic to the main operating program. See figure 
D. Each line of the COMMAND.D/>a' defines items like: current command number, 
next command number, message number, number of digits to accept from the touch tone 
phone, location of the data in the transaction record, and branching based upon the touch 
tone digit entered. 

The HP-3000 host program is written in COBOL. It '*s written to take records from a ter- 
minal and process them against the Student Data Base, and then return a data record 
back to the IBM/AT with the next command number to execute on the IBM/AT. 

An example is a student who calls in to register, but has an unpaid library fine. The stu- 
dent enters his social security number and access code through his touch tone phone to 
the IBM/AT. The IBM/AT under program control sends a request record to the HP-3000 
COBOL program. The COBOL program checks the Student Data Base and finds the stu- 
dent has a "hold" because of an unpaid library fine. The COBOL program sends back a 
record to the IBM/AT telling it to execute a command number that speaks the message 
that the student has an outstanding financial obligation that must be paid before he can 
register. After thanking the student for using the Touch Tone Registration system, the 
IBM/AT disconnects the line. 
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SELF REGISTRATION SYSTEM 



In order to provide easy, convenient access to course information and the registration 
process, a self-registration system was designed. See figure E. Based on the concept of 
self-service, the system allows anyone to check for open courses, course time and course 
location. Full-time and part-time students who have attended Waubonsee previously can 
register for either credit or non-credit courses. Students can check their current schedule 
or courses completed, check their current financial statement, and receive pertinent infor- 
mation regarding the semester calendar. 

During peak registration times, self-registration terminals are available in the Admissions 
and Records area and also in Counseling. Future sites include the extension campus and 
the Learning Resource Center. With a telephone line, a modem, and a portable CRT, 
registration sites are unlimited. 

TIME-LINE 

Brain Storming 

System Design and Programming 
Testing 

Self-registration Available for Use 
SUMMARY 

With these inovative concepts, the old methods of maintaining records and financial ac- 
countable have drastically changed. These systems promote a paperless office environ- 
ment. Due to the lack of paper "back-up", the computer generated listings of detailed 
transactions (audit trails) have become a crucial part of record keeping. Registration staff- 
ing probelms have decreased with the expanded availability of self-service registration sys- 
tems. Part-time staff hirings have been virtually eliminated, with the full-time staff able to 
handle. 

Other advantages of using these systems include: reduced salary budgets, expanded acces- 
sability to academic and registration information, expanded service hours without increas- 
ing the building/staff utilization costs, and providing a needed service for a growing stu- 
dent body. 

With the flexibility of the self-service systems, future inovations are more easily adopted. 
Advertising course availability through the Waubonsee Instructional Television Fixed Ser- 
vice (ITFS station) where students can view selections, call in and register by touch-tone 
registration. Offering a credit card payment service through the touch-tone registration 
system. Allowing students to register through their home computer systems via the self- 
regtistration system. 



February 1986 
May 1986 
June 1986 
July 1986 
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System DOS Platform $ 7,000 
Includes host-interface HW/SW, 
not mainframe program. 

(4) line Module Card $ 9,000 
Max (4) cards per DOS Platform 

Record Facility $ 4,500 



• Prices Subject to Change 
** Maintenance 12% of purchase/year 



$20,500 



Option: 

Credit Card Verification $ 4,500 



O ^ figure A 



WCC Configuration Overview 
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WCC Touch Tone Registration System 
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Joe C. Waubonsee 
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CUDA 

An Adventure in Distributed Computing 



Louise Marie Schulden 
Cornell University 
Ithaca, New York 



ABSTRACT 

With the availability of personal computers and the 
escalating information and reporting needs of univer- 
sities, college administrators arc increasingly develop- 
ing their own systems on microcomputers. The Cornell 
University Distributed Accounting (CODA) system is an 
attempt to institutionalize thic" trend, provide depart- 
Tnents a softv/are tool for better managing their finan- 
ces, create microcomputer standards, create a vehicle 
for better administrative microcomputer support, and 
insure local systems are consistent with central 
computer systems* 

CUDA currently consists of 5 modules: accounting, 
budgeting, perr^nnel/payroll, purchasing and reporting. 
The system provides standard management information 
reports and allows administrators to develop custom^.^ed 
reports* The data can be downloaded from the central 
systems or entered locally. 



ERLC 



50 



528 



Background 

During the past six years there has been a major effort at 
Cornell to computerize the central administrative functions. 
The university has been successful in providing computing for 
many central offices, but until recently has paid little atten- 
tion to departmental administrative computing needs. With much 
of the central system development work complete, Cornell 
Computer Services (CCS) is taking a close look at departmental 
information needs. Since funding and financial decision making 
is decentralized at Cornell, the accounting office was one of 
the first to recognize the need to improve the quality of 
information provided to departments. 

The central accounting system meets the needs of accounting 
personnel who understand and take full advantage of the informa- 
tion provided by the system daily. It does not fully address 
management information needs outside the accounting office. 
Information is disseminated to departments monthly in reports. 
This dated information, along with unneeded data, has proven to 
ba too much and too infrequent for departments to make timely 
decisions. Standard accounting reports are often considered 
difficult to read or insufficient by departmental managers. 
Since a substantial effort would by required by data processing 
staff to create special reports to satisfy over 300 departments, 
many departments have had to do without. 

To alleviate this problem, almost all of the departments 
maintain manual records, and some have computerized their 
financial record keeping. These departments were rekeying data 
from monthly accounting reports so that the data would be in a 
more usable format. Some of the departments hired their own 
data processing staff to write special reports and provide a 
mechanism for keeping data not collected by the central system. 
Because of restricted access to the accounting files, the need 
for special reporting capabilites and the need for more timely 
information, independent systems have been developed and have 
flourished. These local systems often caused more problems than 
they solved. They resulted in inconsistent information between 
the departmental and central accounting systems, and duplica- 
tions in effort. There was a clear risk that if better services 
were not provided centrally, more departments would go in their 
own direction with the danger of misinformation and mismanage- 
ment of departmental funds. 

To meet departmental needs, the accounting office formed a 
committee to execute three goals. The first goal was to provide 
on-line mainframe access to current data^ The second was to 
provide the capability to download data for departmental usage. 
Central financial data has been available for use on microcom- 
puters for a number of years, but it could only be used by those 
administrators with relativel • good computer skills. Procedures 
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for downloading the data were complicated, data reformatting was 
necessary for use in software packages (e.g., LOTUS), and 
familiarity with microcomputer software was necessary. 

The third goal and topic of this paper was to provide 
standards, a support network and a functioning micro-system so 
the downloaded financial data would be efficiently used and 
correctly interpreted according to the guidelines of the central 
system. Instead of designing a central system that would be all 
things to all people, the intent was to make the central system 
information easily available and, at the same time, provide the 
departments with the ability to decide for themselves what data 
they wanted and how they could manipulate it to meet their local 
needs. With downloading, duplicate data entry was no longer 
necessary, and time could be spent more productively. Many 
departments were also developing software to meet their needs. 
This often led to the university paying for redundant program- 
ming. It is hoped CUDA will displace this practice. 



Starting the Project 

So began CUDA, Cornell University's Distributed Accounting, 
The CUDA project seeks to provide a foundation for local 
departmental financial systems. By providing a foundation, the 
departments would be assured of having central system data 
locally available, a basic set of procedures and software for 
using the data, and a common starting point for their local 
system. The departments could build on the foundation of common 
file layouts and programs to meet needs specific to their 
departments 

The CUDA project is guided by a committee formed by the 
Controller's office. This committee consists predominately of 
Cornell administrators, representing large and small, endowed 
and statutory, non-enterprise and enterprise departments. Their 
funding sources (and consequently tracking/reporting needs) are 
as varied as their personalities. They decided what systems 
were needed and developed the specifications for those systems, 
CCS and the central university administration also had represen- 
tation on the committee. 

The committee identified the objectives and defined the scope 
of their study. The overall objectives of the project were to 
provide the departments a trolid foundation for building their 
local office management system which Would be compatible with 
central systems. Functional areas to be implemented would be 
accounting, payroll/personnel, receivables, purchasing, budget, 
inventory. The departments vould be given access to central 
system data and an easy to nse download procedure. Departments 
would be encouraged to share software, computer knowledge, and 
financial knowledge, 
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Scope of the Project: 



1. To decide on appropriate hardware and software. 

2. To work out an easy downloading procedure and ability 
to select and format data in a user specified way. 

3. To define conceptual and technical specifications for 
accounting , payroll/personnel, receivables, budget, 
purchasing, and inventory. 

4. To work with central administrative offices to agree on 
data to be downloaded from the central systems and the 
presentation of the data in local screens and reports. 

5. To set programming and program documentation standards 
for all PC CUDA programmers, including non-Cornell 
staff. 

6. To provide clear documentation, microcomputer training 
(CUDA and general) , security, and back-up procedures. 

7. To allow for additional files and data elements to be 
used by the local systems. 

8. To provide a core set of programs to handle data entry 
and reporting and data extraction and downloading from 
central system ADABAS files. 

9. To provide a hotline for problems and questions, help 
available on microcomputers, mainframe, CUDA, accounting, 
payroll/personnel, writing custom software. 

10. To start a bulletin board and software library for 
administrative users where new software, helpful tips, 
and financial news can be posted. 

11. To form a CUDA users group to share ideas and software. 

12. To establish a procedure to evaluate CUDA. 

The committee of departmental adipinistrators gathered a list 
of departmental needs that resulted in a system of 6 functional 

subsystems accounting, accounts receivable, budget, payroll/ 

personnel, purchasing, and inventory. Each functional module 
was given to 2-3 committee members to write a conceptual design 
and specifications. All the designs were put together into a 
specifications document and the entire committee reviewed the 
document for completeness. Once the committee was satisfied 
with the conceptual design, administrators, deans, directors and 
department head-* were invited to review the project's specifica- 
tions. 

Once the conceptual design was complete it was obvious to all 
that the project and time/resources needed were too large. 
Accounting and Budgeting modules became a manageable phase one. 
Payroll/Personnel would be phase two followed by Pur'^hasing. 
Committee members aided in the development of technical spec- 
ifications from their conceptual design. Lists of needed files 
and their data elements were created. Central system files for 
accounting and payroll/personnel were reviewed for data elements 
needed by the local system. 
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Armed with file descriptions (data elements, size of record, 
number of records in worst case) and system specifications^ the 
hardware and software options were investigated and requirements 
set. When considering hardware for this project it had to be 
produced by a stable company, have a large base of users on the 
Cornell campus, have a lot of software available, be reasonably 
priced (under $5,000), expandable, and CCS supported. The 
IBM-AT filled these requirements and has the power necessary to 
run the system, in addition to the IBM-AT, several IBM compat- 
ible also met the requirements. 

When considering database software for this project it again 
had to be a stable company, have a large base of users on the 
Cornell campus, reasonably priced, easy to use, would support 
networking, and, if it was a programming language, it should be 
able to be compiled. The database users on campus were split 
between RBASE and DBASEIII. The ones seriously considered were 
RBASE, DBASEIII, PCFOCUS, and PARADOX. PCFOCU' is disqualified 
because of co3t. PARADOX was disqualified bee of newness of 
the company. RBASE and DBASE were very similar, but DBASE was 
chosen. RBASE was easier to use than DBASE and slightly faster, 
but DBASE had such a following on canpus and in the general 
market that it was felt that Ashton-Tate and other vendors would 
improve and supplement the DBASE software. 

The final and most important job of the committee was to keep 
the departments abreast of the project's progress, get suggest- 
ions from the departments and manage departmental isxpectations . 
This was done by periodic questionnaires, interviews of users, 
and open review sessions. It is important that departments 
understand what the project is trying to accomplish and when. 



Software Development 

Four people were involved closely with the software develop- 
ment. Business manager for the Johnson Graduate School of 
Management served as chairman of the CUDA committee and, on a 
daily basis, answered system specification ques'>ions for the 
computer staff. The Johnson School of Management also provided 
a full-time programmer with a background in micro-systems. The 
Controller's office provided a full-time person to test and 
document tha system as it was being written. Computer Servicer 
provided a full-time analyst/programmer with a background in 
mainframe financial systems and a hobbyist's interest in 
microcomputers. The four people were housed in the Johnson 
School which served as one of the four alpha sites and provided 
the computer staff close contact with a user. 

Ear.l.y on, standards were set for CUDA programming. The goal 
was to achieve consistency in outward appearance of the system 
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and internal programming code. To that end, standards dictated 
the use of: 

1. Naming conventions for programs, files, variables, etc. 

2. Centralized source code and log of changes. 

3. Generalized program routines (i.e. error handling). 

4. Consistent special key handling (i.e. CTRL-HOME adds 
a record) . 

5. A restriction to use only DBASE program code; no use of 
DBASE exits to call other programming languages including 
use of features that were exclusive to look alike products 
such as Clipper and FOXBASE. 

6. Programming standards such as the use of "IIF" (immediate 
if) over "IF...ENDIF" because of faster execution time 
except if program readability was jeopardized. 

7. Use of indentation and capitalization to aid in program 
readability. 

As programs were finished they were given to the alpha 
sites. The alpha sites were now part of the project committee. 
At bi-monthly meetings, the project team reviewed problems and 
enhancements with the alpha sites. The committee decided work 
priority. For several months, this iterative process occurred i 
programming, release to alpha sites, requests for change or fix, 
committee review, scheduling the work, programming, and so on. 
When most of the requests were for enhancements and not bugs or 
problems, then preparation began for beta testing. 



Coordination with the central systems 

As a bi-product of the CUDA committee came some standard- 
ization of terminology. As the systems technical specifications 
were written and reviewed by departmental managers and central 
administrators a common vocabulary was agreed upon. 

Access to central accounting files is granted based on a 
department having a mainframe computer user id. That user id has 
read access to specific account information. Departmental users 
can request central accounting to give them access to informa- 
tion concerning their departmental accounts. If accounting 
approves the request, the computer user id can then be used to 
access central accounting information for downloading to their 
local system. 



Alpha and Beta Testing 

The alpha test suites had to satisfy several criteria. Their 
business manager (user of the system) had to be well versed on 
Cornell's financial practices and procedures. Someone in the 
office had to be computer literate. The office had to have the 
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equipment necessary to run the system and perform the down- 
loading from the mainframe. Most importantly, the alpha site 
had to understand and accept the fact that the software was 
bound to contain some errors. The beta sites were chosen to 
represent every college at the university and to form as diverse 
a group as possible. 

Both the alpha and the beta sites are responsible for testing 
and using the software and reporting any problems or enhance- 
ments desired. All test sites are given forms to fill out to 
request changes or report problems. If a problem occurs they 
are requested to also call, so action can be taken as soon as 
possible. Requests for changes or enhancements are taken up in 
committee meetings. 

The computer personnel currently includes 2 technical 
consultants and 2 analyst/programmers. The 2 technical consult- 
ants are responsible for user assistance, system documentation, 
training, general communication (newsletters, demonstrations), 
and some maintenance programming. The analyst/programmers 
continue fixing problems and new deve?opment. The goal when a 
problem is reported is to fix it within 48 hours. Another group 
goal is to have someone knowledgeable covering the phone from 
8:30 to 4:30. This sounds trivial, but with microcomputer 
systems much of the work has to be done at the user site, taking 
staff away from their office. 



Short and Long Term Support 

The computer support staff for this project currently 
consists of 2 technical consultants and 2 analyst/programmers. 
It is predicted that this level of staffing will be needed until 
the major modules (the 6 modules originally defined) are 
completed. After this time only the 2 technical consultants 
will be required. Currently these consultants spend most of 
their time preparing documentation and training users. The time 
required for this is expected to dwindle and be replaced with 
maintenance and enhancement programming. 

This may seem like insufficient staffing tor a system that 
could have over 300 users. It is hoped that from the project 
committee and from the alpha and beta sites will spring a user 
support network. There are indications that this is already 
happening. A goal for the 2 technical consultants is to provide 
a focal point for this activity, to help the network formation 
along, and to give the group a communication link into central 
computer services when greater computer technical expertise is 
needed. It is also expected that the project committee will 
continue to offer guidance to the systems users, encourage the 
user network, and provide a communication link with central 
administration to voice departmental needs. 
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Problems 

The most obvious problem with the system is response time. 
DBASE is not noted for its speed. When the budget data entry 
programs were complete they were tried on an IBM-XT. They ran 
painfully slow. Thus the requirement of an AT was made. 
Compiling the programs helps and products such as FOXBASE (a 
DBASE look alike) greatly improves the execution time of the 
code (3-9 times) . With improvements in the software and larger, 
faster machines becoming the status quo, this will no longer be 
a problem. 

Another problem is that of maintaining current source code. 
Though installation disks are currently used, the programs are 
changing quickly and it is impractical to send floppy disks with 
updates to all the user sites. Instead, program code is 
uploaded to the mainframe, and made available for downloading. 
This has the drawback of making the user responsible for getting 
arid keeping their local software current. A bulletin board on 
the mainframe informs users when and which programs have 
changed. 

Access to the mainframe data is controlled by userid. Once 
that data is downloaded it is the user's responsibility to see 
to it that data is in a secure place. A public machine is no 
place for financial data. Right now, CUDA has no way to limit 
where that data is stored. Whenever the system is set up at a 
new site, file security, machine security, and the confidential- 
ity of the material is stressed. The security of the informa- 
tion relies heavily on the attitude and precautions taken by the 
particular office. There have been no incidents to date, but we 
are vulnerable in this area. Programs for hard-disk locking and 
securing are being investigated. To date none appear worth- 
while. 

The synchronization of central systems can not be guaranteed 
unless the user is religious about downloading or locally 
entering all information. For example, if a user forgets a 
week's download then their local month-end bottom line will not 
match the central reports. Most departments do run the CUDA 
reports that match the central system to compare bottom lines 
before running their special local reports. CUDA is a local 
system, under departmental control, so the department has to 
take responsibility for the data in the system being current and 
correct. 

The final problem was a bit of a surprise: free-lance 
sabotage. CUDA was not meant to do away with departments 
employing free-lance programmers. It was supposed to reduce the 
amount of redundant free-lance work that the university was 
contracting out. Non-Cornell programmers were told about the 
project and the source code was shared with them in the hopes 
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that if they did customizing work, they would follow CUDA 
standards and integrate the work closely into the system. If 
the work was of general use it possibly would be incorporated 
into the general system to be used by other departments. Some 
outside programmers viewed the system as a threat and proceeded 
to criticize it to their departmental clients. Some of the 
heaviest criticism CUDA received was not from departmental 
users, but from outside progransr-ers hired by the departments. 
Tine will cancel any bad press they caused. 



Successes 

One of the major contributions of CUDA was the preparation of 
more flexible financial management reports. And if CUDA did not 
provide the needed report, the means to write a custom program. 
Many of the CUDA reports are table driven. The department sets 
up object codes, budget categories, etc. the most meaningful way 
for their department and the reports print, subtotal, extract, 
etc. that way. In addition to table definition by the depart- 
ments, several local data fields were added to the files. These 
too are used to customize reports. Better reports, more in step 
with the particular department's needs means better use of 
financial information. This, in turn, should help the depart- 
ments make better financial decisions. 

The departments are more tolerant of the shortcomings of this 
system then any other I have worked on. I believe the reason 
for this is twofold. First, it is their system. From concep- 
tion, many departmental managers were involved in the conceptual 
design, the technical specifications, the testing, and the 
documentation. They got to observe and have input into the 
development at every step. Computer staff worked as technical 
advisers and aides to create the system that business managers 
were imagining, if we went up a blind alley it was a user who 
sent us there. Secondly, the departments have been tolerant 
because we have built in the flexibility for growth and change. 
If additional reports or additional data fields are needed, 
users have been given the ability and right to add both to the 
system. The openendedness and control over the ultimate system 
has made the departments very satisfied. 

Departments still have local information which the central 
system does not keep, nor will keep in the future. But with the 
downloading of data, the departments are not rekeying informa- 
tion and are more aware of how the central accounting system 
views their financial position. With the more flexible report- 
ing, the additional local data fields and the downloaded data, 
departments are more and more regarding central accounting 
records as their records. They are more aware when central 
records are wrong and are more willing to take action to correct 
not only their local rcicords, but also central records. 
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By-Products of the Project 



A number of standardizations have occurred as a result of 
this project. DBASE has become the database for many admin- 
istrative users at Cornell, DBASE may not be the best micro- 
computer database on the market, but having a standard makes 
support and future system compatibility possible. Standardiza- 
tion of financial software on the microcomputers is being 
achieved. Standardization of terminology and general knowledge 
of computers is helping us communicate with each other more 
effectively. 

The local system is helping departmental administrators 
analyze and project their future needs. They are using the CUDA 
committee to communicate those needs back to the central 
administration. This is helping central administrative offices 
to become more responsive. 

Finally, business managers in general are becoming more 
computer literate. With this exposure to microcomputers, many 
are branching out and automating other aspects of their opera- 
tion. 



Future 

The pace of the CUDA project has not slowed down. Work 
continues on the other modules and incorporating enhancements to 
existing work. One of the major enhancements in progress is 
budget development software that allows different financial 
scenarios. Work already done by departmental programmers is 
being reviewed to see if it should be included in the system. 
When such software is found the programs are reviewed and 
modified, if necessary, to be compatible with the ovex'^11 CUDA 
software and the corresponding central system (if one exists) , 

Other hardware/ software options are continuously being 
investigated. With several companies coming out with DBASE or 
DBASE look-alike software for the Apple Macintosh, CUDA will 
hopefully be running on the Macintosh before the end of the 
year. In addition, FOXBASE has been found- to run DBASE code 
with no modifications but 3-9 times faster than DBASE, We are 
in the process of converting CUDA users to FOXBASE. 

In addition to microcomputers, larger offices have expressed 
an interest in CUDA on minicomputers. And finally the topic of 
uploading is being discussed for budget preparation. It is too 
early to say how that will develop. 
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Conclusions 

This is clearly a large project with great opportunity for 
success and failure. Though possibility of failure is great, 
success will save the university a great deal. Microcomputers 
are now available to almost every department on campus. Not 
diresiting the use of these microcomputers in administration will 
cost in wasted administrative resources and poor management of 
departmental finances. 

The benefits of this project are many. Some have to do with 
financial information and management and others have broader 
impact. It is difficult to describe, let alone calculate, all 
of the benefits derived from the project because financial 
information touches all areas of the university. 

Downloading of data saves time for departments who were 
rekeying information from central system reports. In addition, 
the procedures and techniques developed for easy selection, 
downloading, and formatting of mainframe data can be applied to 
data other than financial. 

Second is a structure which administrators can follow to 
become familiar with microcomputers and their use for things 
other then CUDA. CUDA has had an opportunity to set some 
standards for microcomputers in administrative use. For many 
administrators it will be a way to gain familiarity with 
microcomputers in their world and expand computer usage. 

Microcomputer software and downloading will give offices a 
foundation to view central financial information without always 
accessing and paying for connect time on the mainframe. In 
addition, the provided programs will give examples and set 
programming standards to help the departments with their own 
custom programming. 

Departments often complain that there are additional data 
elements that they would like to track. The data elements can 
be added to the local system and used in conjunction with 
downloaded data from the central system. Also departments 
complain of the timeliness of data. There will always be some 
time lag between a department's records and the central system. 
This cannot be helped, but with the local system, departments 
can flag information as pending until it clears. That way a 
record exists. Of course, having the data available on a 
microcomputer provides every department the opportunity to 
develop reports that fit their needs and allows a department to 
keep as many years of historic data as it wishes. 
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THE FOUR YEAR ID 
Roth Aymond 
Louisiana State University 
Baton Rouge 
Louisiana 



The development and the integration of a Student 
Records Data Base and the Human Resource Management 
System made it possible for LSU to provide current 
status information about students and employees to 
nearly every administrative department on campus . 
Online access eliminated the need to record status 
information i.e. major, year classification, 

f ulltime/parttime status, etc. on the ID. 

Having online access and adopting the ANSI standards 
for Bar Code and Magnetic Stripe technology on the same 
card made it possible for LSU to design one, permanent 
ID card for all known and anticipated ID card 
applications on campus. This discussion will highlight 
the design of the Four Year ID and its application for 
Football Ticketing, Food Service, SGA Elections, 
Library Circulation, Building Security, Time and 
Attendance Reporting and other applications. 
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INTRODUCTION 



Louisiana State University, the flagship institution of the LSU 
System, was founded in 1860 as the Louisiana State Seminary of 
Learning and Military Academy in Pineville, Louisiana. The school 
was moved to Baton Rouge in 1869 and in 1870 was renamed 
Louisiana State University. LSU supports approximately 28,000 
students with a faculty and staff of about ^,500. 

The LSU administrative computing environment is served by an IBM 
308^-QX mainframe. Most administrative applications have been 
developed using COBOL in conduction with IBM's IMS DB/DC, an 
hierarchical data base /data communication product. Two very 
important applications utilizing this product are the Human 
Res(;urce Management (HRM) system, a payroll/personnel data base, 
and the Student Records and Registration (SRR) system, a student 
information data base. Both were essential to the development of 
the Four-Year ID System. New development in these areas are 
continuing with design interfaces to DB2, IBM's relational data 
base management system. 

The Four-Year ID system was designed using the IMS product and is 
integrated with the HRM and SRR systems. The Four-Year ID is Zi 
very important tool used throughout the campus environment. LSU 
has many departments which interface with or are interfaced by 
the Four-Year ID. This discussion will focus on the ID Office, 
Records and Registration, Personnel Office, Athletic Department, 
Student Government Association, Food Services, and the Library. 

The integration of the Four-Year ID with the University 
information base creates a very useful and powerful asset. The 
key to integrating the ID into the mainframe environment is the 
automatic identification technology which allows data to be 
entered without keystrokes (keyless data entry). This "keyless 
access" to the information base can take many forms. One of 
these forms is the "machine readable" ID card. 

For the purposes of this discussion a "machine readable" ID means 
any ID which contains information which can be read and 
interpreted by a machine without human intervention. There are 
currently three major types of media specifically designed for 
this purpose: OCR, bar code, and magnetic stripe. OCR (Optical 
Character Recognition) is a special type font designed to be read 
optically. A bar code is an array of rectangular marks and spaces 
in a predetermined pattern recognizable by a bar code scanner. 
Magnetic stripe is very similar to an 8 track tape in that the 
magnetic material can contain several tracks and each track can 
be encoded with information . 
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The purpose of an ID containing the machine readable media is to 
allow functions to be performed without having to manually 
keystroke the data. Therefore, the information encoded on the ID 
card must at least logically relate to the data being retrieved 
or updated. The index or key used most often by an institution 
will be the most likely candidate for use on the ID. 



BACKGROUND 



For many years LSU had issued ID's in the fall semester to 
enrolled students. This ID would be used throughout the academic 
year. In the succeeding fall semester a completely new ID would 
be constructed and issued. Every year nearly 30,000 in^ had to be 
produced. The cost of producing these ID's was significant. One 
of the reasons LSU had not gone to some type of career ID card is 
that the athletic department used the card for football 
admission. The ID card had a row of numbers along the bottom 
which were punched with a hole whenever a student picked up a 
football ticket. The hole signified that the student exercised 
his privilege for that particular game. By the end of the 
football season the ID was punched to pieces. Student Goverment 
elections and Homcomeing ;lections also required the row of 
numbers tc indicate that a privilege had been exercised. In 
addition to this the Library punched the hollerith code into the 
card. The hollerith code was used by the library circulation 
system. After a year of this type of destructive encoding, the 
card became virtually useless. It was then replaced, and the 
process started over. 

Another contributing factor involved a decision by the 
administration to automate many of the functions of the library. 
The library purchased a proprietary software package called NOTIS 
(Northwestern Online Totally Integrated Library System). NOTIS 
contains a library circulation module which requires that a 
patron have some form of machine readable identification. NOTIS 
recommends using one of the major bar code symbologies such as 
Code 3 of 9, Interleaved 2 of 5, or Codabar. 



OBJECTIVES AND METHODOLOGY 



In 1985, the Chancellor of the University decided it was time to 
modify its existing ID design and procedures. Therefore, 
university managers agreed to change and the following overall 
objectives were established: 
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» Produce the ID in "machine readable" form, 

* Enable an individual to retain the ID throughout career, 

* Provide a means for greater security and control, 

* Utilize existing data currently residing on the mainframe. 



The introduction of a nev/ ID on campus can be a very involved 
logistical problem. The initial stages are very critical and 
cooperation across departmental boundaries is required. The mass 
production and distribution of the new ID must be carefully 
planned and executed. Proper controls must be exercised during 
the initial distribution in order to insure data integrity ari 
security. 

The coordination of a project like the Four- Year ID is very 
complicate.^ because it crosses so many departmental boundaries. 
It require.. a very strong sponsor. The Chancellor was the 
executive sponsor of the ID project. He set the objectives and 
delegated the responsiblity and authority to a project leader. 
With this type of backing, disputes between departments were 
easily diffused. 

The development methodolgy used at LSU is a modified version of a 
method developed by IBM* There are six steps to this development 
process. Each step builds upon the previous one and allows 
management several checkpoints to review and consider the project 
as it develops. 

1) Requirements Definition 

The functions of the organization are analyzed and the 
-scope of work is defined. 

2) External Design 

The Requirements Definition is used as a blueprint 

to develOf* the overall conceptual design of the system that 

will carry out the objectives of the scope. 

3) Internal Design 

The data base struture is defined and program specifications 
are prepared • 

4) Program Development 

The application programs are written and tested. 

5) Demonstration and Installation 

The users are trained and the application is implemented. 

6) Maintenance 

Continued analyst support for the lifetime of the system. 
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Most of the projects associated with the Four-Year ID have been 
completed within very short time frames. Unlike most development 
projects, which are strictly software projects that rely on 
existing hardware conf igurat ions t the Four-Year ID required 
extensive research into available automatic identification 
technology. Because of Louisiana purchasing laws, complex bid 
specifications had to be written. From the outset, it was decided 
that it would be expeditious to reveiw the available 
hardware/software at the same time the requirement definition and 
external design were being written. This analysis enabled the 
project leader an opportunity to prepare a cost/benefits proposal 
early in the development process. 



SYSTEM FEATURES 



There is a very strong correlation between the system objectives 
and the system features. The project, from the start had a very 
real purpose and direction. 

LSU produces its own ID cards. This has proven to be very cost 
effective and expeditious. Cards are produced at registration, 
which is a mass production type process, and again during the 
sem<ister to replace lost IDs, new employees, etc. LSU issues no 
temporary cards. 

The process used at registration is for new students. Prior to 
registration, a label is printed for every eligible student. The 
data label is 1-1/2 inches tall and 2 inches wide. The label is 
then affixed to a "carrier card," which is a fan folded card 
stock with a blank label. The label is printed with the students 
name, student id number, and bar code representation of the id 
number. The label information is obtained from the Student 
Records data base used to produce registration packets. The 
label is printed on a Printronix ^160. The printer is connected 
to the mainframe via IBM Z27^ control unit and QMS wedgebox. If 
a student has registered late or has lost his ID, the label is 
produced at registration using the Printronix printer with a PC 
as the host. During the semester, ID's are produced online from 
the IMS ID update program. The Printronix printer is used in 
this configuration also. 

At the present time the carrier card is stuffed in the student 
packets which are picked up at registration. The new students 
need to bring the carrier card and fee bill to the ID station at 
registration to have their ID made. The ID station takes the 
student's picture, peels off the label from the carrier card and 
affixes it to the ID chip, then .they die cut the picture, place 




65 



it in the ID chip cutouts the stutSent sign's the card, and then 
the card is run through a laminator* The chip is a polyester 
laminate which has a cutout for the picture, ana the magnetic 
stripe is affixed to the back layer of the laminate. The ID cards 
are electronically validated by updating the ID data base with an 
interface program to the Student Records data base* 

During the Spring of 1989 the old auditorium registration 
procedures will be replaced by the Telephone Registration system* 
The carrier card will still be used, but it will not be stuffed 
into the packet. Procedures are defined which will allow the new 
student an opportunity to have their ID card made at the Student 
Union, a central geographic location* The student will be 
required to present the registration confirmation document* The 
Telephone Registration system is another major step for the 
University* It demonstrates the advantage of integrated systems* 

The Four-Year ID is the only ID card pr\,duced and used on campus* 
It is used for all applications which require some type of 
identification* One set of data is maintained on these IDs for 
each individual who has been issued an ID card* 

The ID data base contains a segment (or record) for each ID card 
issued* It eliminates the old cumbersome manual card file that 
was kept to verify that a student was issued an ID card* The 
major relationship between systems is the ID number symbolized by 
the bar code* With this number any data contained in the Student 
Records data base or Human Resource Management data base can be 
accessed through the use of the ID card* 

The ID number is composed of the student or employee number, a 
type code, a sequence number, and a check digit* The type code 
is a one digit identifier between employee, students, and other 
defined groups* The sequence number is a one digit code 
identifying the number of ID*s an individual has had* The 
sequence number is very important because it uniquely identifies 
each ID* The check digit is used to assure data integrity* 



The Four-Year ID dat« base is an IBM IMS DB/DC data base* The 
Ctata contained in this fil3 can be accessed by either online or 
batch programs* The LSU ID office has the capability to online 
update the ID data base* This enables all applications using the 
ID data to obtain the latest information. It also allows the ID 
office to print the ID labels from the same online program* When 
a new ID is produced the data base is automatically updated* The 
data is always available for immediate access and the information 
is current. 
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The most important feature of the Four-Year ID card is its use of 
two types of electronic identification technology - bar code and 
magnetic stripe* The bar code has a high read rate (99%), can be 
read from a distance, is inexpensive to produce on demand, and 
its low error rate compared to other means of data entry is 
significant. The magnetic stripe is 5/8 inch, and can contain 
all three ANSI defined tracks. The magnetic stripe is able to be 
encoded with information in a high density and the data on the 
stripe can be altered. 



The card size is important because it accommodates the industry 
standard specifications on card reader hardware. The majority or 
automated teller machines, security access devices and various 
data collection devices require that the card meet ANSI credit 
card size specifications. 

The physical properties of the Four-Year ID are all defined by 
the American National Standards Institute (ANSI). The card is 
credit card size, the dimensions (l^i'ngth, width, and thickness) 
are defined by the Institute within tight tolerances. The size of 
the magnetic stripe, its location on the card, the location of 
the tracks on the magnetic stripe, the format and location of the 
data on the tracks, and technical encoding specifications are all 
defined by the ANSI publications. The bar code symbology. 
Interleaved 2 of 5, used by the Four-Year ID is also covered by 
Automatic Identification Manufacturer's specifications as well as 
the ANSI standards. 



The use of ANSI standards is ext; emely important to the writing 
of bid specifications for the procurement of equipment. Because 
most manufacturers design their equipment around the ANSI 
standards, it is advantageous to design the ID card to work with 
standard equipn:2nt. Another important aspect is that the 
specifications are so tight that it is very unlikely that a 
manufacturer will bid a piece of equipment that does not meet the 
specifications. 



Information about the ID is stored for as I ^ as necessary. The 
fields which deal with dates of issuance, last update, and 
expiration date are very important and are retained for the 
conceivable life of the ID card, which is determined only by the 
proper care of the card. Of course, the IMS data base must be 
purged periodically. 

The ID data base is a separate and distinct entity but it 
accesses several other data bases in its day to day operations. 
This information from other data bases is used to determine 
privileges, elgibility, and status. Redundancy is reduced through 
this means. Other applications utilize the information stored in 
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the ID data base. These interfaces are very important and add a 
measure of security which were not previously available. 



INTERFACES 



The integrated application computing environment at LSU promotes 
the usefulness of the Four-Year ID system. The ID system 
interfaces with many of these systems. The ID data base was 
designed to interface with every anticipated application. The 
source of this ability is the coded information on the card. The 
information represents the index configuration used in all of our 
datdi base structures. 

The Registration interface is very simple in principle, ID data 
cards are produced for eligible students from registration system 
information. At registration time» ID cards are constructed and 
the information is loaded to the ID data base. Immediately after 
walk-thru registration, information from the registration system 
is used to electronically validate the ID data base. 

Information from the Student Records data base is used in many 
phases of the ID system. Full/part time status with respect to 
hours carried, athletic privileges, and SGA voting privileges are 
updated constantly. For many of the subsystems this information 
is captured online. The ID update screen used by the ID office 
contains online information from the Student Records system which 
is used to determine eligibility and status. 

Employee (Faculty/Staff) information is captured by the ID system 
online for the verification and production of employee ID's, 
There is current development work in progress which will utilize 
the HRM data bese and the ID data base in conduction with the 
Four-Year ID for employee time and attendance tracking. 

An unique interface came about as the result of automating the 
policies and procedures associated with the ID hole punching by 
the LSU Athletic Department, The interface was required to adhere 
to the following objectives: 

^ Allow students to purchase season tickets, 

^ Allow students to select the game(s) desired, 

^ Allow student:; who did not receive season 

tickets to purchase the remaining tickets, 
^ Check the status of the students at the student 

entrance gates at game time to insure only 

full-time students are entering. 
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The Season Ticket System required a combination of several 
different technologies. For example, a ticket application is 
filled out on optical scanning sheets. These sheets are read and 
data sets are built. Student elgibility is checked via inquiry 
to the Student Records Data Base and priorities are established 
based on LSU hours earned. Seats are matched to students and a 
tape is prepared which is sent to a ticket printing vendor and 
tickets are produced. The information used to create the ticket 
tape is also used to produce a file of the cost of the individual 
student season ticket packages. This file is downln Jed to an IBM 
PC/AT micro computer and is used in the purchase/pickup 
operation , 

The purchase/pickup operation utilizes bar code technology. When 
a student purchases his ticket package, the ID card is scanned 
and a flag is set indicating that student paid for the ticket 
package. This information serves two purposes: 

* Accounting information is recorded for 
audit and balancing purposes, 

* Ticket information is recorded to insure 
students are only able to exercise this 
privilege once . 

Remaining tickets are sold on a first come basis. Student 
eligibility is checked on^.ine under IMS using laser wedge readers 
as input devices and this ticket information is stored along with 
previous season ticket information. 

The game admission operation at the student footbaTl gates 
"^ilizes bar code technology. Student status is obtained from the 
Student Records Data Base and downloaded to an IBM PC/AT at the 
stadium. Bar code readers are attached to the PC/AT and student 
status information is transmitted to the reader display* 

Tiie SGA Voting System is very similar to the online Ticket 
System. Each voting station has a terminal connected to the 
mainframe and each teminal has a bar code wedge reader attached 
to it. When a student requests a ballot the ID card is scanned. 
The scan invokes an IMS online program which checks the 
eligibility of the student and flags the student as having voted. 
Any subsequent scan would reveal that the student has already 
voted . 

The Food Service system is a very sophisticated meal plan access 
system. It utilizes the magnetic stripe for its cafeteria access 
method. The system is a hybrid between a micro computer and the 
mainframe. The CBQRD software/hardware package contains all of 
the communication and access programs necessary to control 
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admission to the cafeterias. The mainframe is used to load the 
meal plan access master file at the beginning of the semester 
with eligible students and their biographical information. It is 
also used to store the daily transactions for historical 
reporting. All of the communication to the uiainframe is 
accomplished through 3270 emulation protocol. Communication from 
the PC to the cafeterias is performed with line bridge/amplifiers 
and modems. Moderns are built in to the magnetic stripe reader 
hardware . 

The NOTIS (Northwestern Online Totally Integrated Library System) 
package purchased by the Unive^vsity has been implemented with 
much success. Before NOTIS^ library circulation was a problem. 
The old id's were void of any type of security and the check out 
procedure was time consuming and cumbersome. The NOTIS system is 
a bar code system which utilizes the Student Records^ HRM^ and ID 
data bases to build and maintain the Patron data base. The Four 
Year ID is scanned to pick up the patron ID number and is 
associated with circulating books. The Patron data base is 
updated weekly during the semester^ but can be updated on demand. 



SYSTEM BENEFITS 



The introduction of the Four-Year ID hs.s had a significant impact 
on the University environment. The benefits are many as it has 
allowed the implementation of innovative applications which have 
benefited both the students and administration. 

Because the card is not tied to the status of the individual it 
need not be replaced each time the individual's status changes. 
This fact eliminates the long lines previously associated with 
the mass production problem of redistributing ID's each year. The 
machine read capabilities allow applications to accurately and 
easily process the card for various fuctions. 

The use of the ID sequence number gives a measure of security not 
known before. It uniquely identifies each ID. When an ID is lost,, 
th J ID Office is notified and the lost ID can be invalidated 
immediately through the online update screen. All applications 
which interface with the ID system at that point know the status 
of that ID. This prevents abuse of the ID in those applications 
such as Library circulation^ Football ticketing^ SGA elections^ 
or any system that interfaces with the ID data base. A hard copy 
of the carrier card is kept which validates the fact that the 
individual was issued an ID card. The ability to query and 
update the ID data base in an online mode and receive the answer 
immediately gives the user the latest verifiable information. 
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The Four-Year ID is not tied to any particular system or 
individual status. Its key is the same key on the data base which 
allows it to be used by any application. For low cost operations 
there is still a visual validation sticker applied to the ID card 
each semester. An individual's status can be verified online and 
through the visual validation sticker. The computer validation is 
done at registration each year. 

The ANSI standards used allow for the continued growth and 
built-in flexibility of the Four-Ysear ID. The University will 
continue to take advantage of the new technology adhering to the 
ANSI standards, build on themt and use them in the future as we 
embark on innovative applications. 



CURRENT DEVELOPMENT ACTIVITY 



Time and attendance is probably the next major development 
interface. The hardware and software to integrate the Four-Year 
ID into the Payroll System is available. The requirements 
structure is being defined at this very moment. Another proposal 
being prepared right now is for restricted building access. It 
will use the magnetic stripe and a personal identification number 
(PIN) with a stand alone reader/keypad. Departments will code 
their own restrictions. Other applications such as check cashing 
and debit card use are feasible and the Student Union is 
interested in both of these concepts, but resources have not been 
assigned to these projects. The Student Health Service is 
investigating the use of the Foui — Year ID card in conjuction with 
a medical records system. 



CONCLUSION 



The implementation of the Four-Year ID has been very successful. 
It has generated enthusiasm for many other applications and 
continues to do so. The concept of the Foui — Year ID being a 
"career" type card has allowed the University to build upon the 
original design. The importance of meeting the original 
objectives has positioned the University to take advantage of an 
excellent tool that is gaining momentum and importance in the 
campus environment. 
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The Development of a Successful Microcomputer Network Operation: 
Winthrop College's Novell NetWare LAN's 

William J* Moressi 
C. Brown McFadden 

Academic Computer Center 
Winthrop College 
Rock Hill, SC 29733 



ABSTRACT 



Implementation of a high-speed, Local Area Network (LAN) can provide 
the educator with a very valuable teaching tool for information 
processing. However, there are many pitfalls and subtle, but significant 
ramifications inherent in the selection, installation, and implementation 
of such a system. Experience is an excellent teacher when it comes to 
networking microcomputers and Winthrop College has; had its share of 
that form of education. The Academic Computer Center currently 
operates three networked, instructional laboratories with over 85 nodes. 

This presentation will include our reasons for choosing a LAN- type 
system, development of specifications and selection of a particular type 
of LAN. The technical aspects of installation and implementation will be 
reviewed. Recommendations from experience and statistics on usage will 
be discussed with some comments on our plans. 
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Microcomputers are pervasive not only in government and industry, but also in colleges and 
universities. The impact of vhii segment of the computer revolution is changing the educational 
process with the aim of integrating computers into every part of the system. The intent is not 
only to provide for a student's smooth transition to professional practice, but to enhance the 
student's learning process in all areas of education. 

Winthrop College has undertaken this challenge of integrating computers into the educational 
process with fthe implementation of several very successful LAN applications. The Southern 
Business Administration Association has presented Winthrop's SBA an honorable mention award 
for the project "An Innovative Approach to the Acquisition and Integration of Microcomputers 
into a Business School Curriculum.'* This report will review some of the major steps taken in our 
effort to computerize the curricula at Winthrop College. 



Evaluation and Selection 

Why a LAN? 

The Department of Computer Science and the Academic Computer Center at Winthrop College 
are organizationally under the School of Business Administration. Two faculty committees, one 
from the Computer Science department, the other from business departments, were formed to 
evaluate how best to use current tools of information technology in their respective curricula. Two 
members of the Academic Computer Center served on both committees for technical support and 
coordination purposes. 

The Computer Science committee focus'id primarily on its commitment to teaching computer 
literacy to non-majors and beginning computer science majors. The committee representing busi- 
ness departments chose to be as diverse as possible in their considerations by including their entire 
curriculum. 

Of the many facets of computer literacy education, two items were common to the faculty 
committees* deliberations. These were to provide the students with the ability: 

1. to describe the components, operation, and uses of a computer, and 

2. to use major application software effectively in problem solving. 

Several other aspects of computer literacy were determined, but not common between computer 
science and business. As an example, computer science wished to teach structured programming 
to its majors. These additional requirements posed no difficulty in establishing our criteria for 
selection. However, it was important that the LANr selected be able to execute all functions 
designated by the respective committees. 
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Micro-based system laboratories with major application software in database, spreadsheet, 
graphics, and word-processing were determined to be the most effective vehicle to support these 
objectives. There were to be three laboratories, two for business education and one for computer 
science. Two laboratories, one business and one computer science, were designed for scheduled 
classroom use. Each of the two labs included an instructor's workstation and color video projector 
monitor. The third laboratory was planed as an open, walk-in facility with no scheduled classroom 
use. 

Based on the nature of the software selected and on the course laboratory structure, several major 
characteristics of the microcomputer laboratory workstations and the laboratory environment 
were determined. 

The microcomputers were: 

to be complete computer systems with such features as maximum memory and 
processor speed to handle major software applications. 

to have both parallel and serial communications, enhanced graphics capabili- 
ties and high resolution color monitors. 

to be able to share several expensive resources such as hard-disk storage, high- 
speed printers (laser and dot matrix), and plotters. 

The micro-based system laboratory was to have: 

a very fast response time in downloading major application software packages. 

a menu-driven turnkey system with security provisions, 

the capability of quickly spooling printer files to a large buffer where they 
could queue to high speed printers. 

the ability to send electronic messages, transfer files, and protect software and 
data at various levels. 

The above features describe the automation of "internal" data communications within a cluster 
of microcomputer workstations. These features identify what is often termed "local area 
networking*'. We determined that this type of solution best met our needs in teaching computer 
literacy. 
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What type of LAN? 

Local area networks arc most often classified by bandwidth, topology, and protocol. A brief 
description of each of these network types is : 

Bandwidth - the data path or channel capacity of a network. This is a measure 
of the network's ability to transmit and receive information. 

Topology - the physical network structure. Network topology describes the 
arrangement by which the workstations are physically and electrically con- 
nected. The star, ring, tree, and bus are four geometrical structures most 
commonly employed. There are physical (hardware structure) and logical 
(signal paths) approaches to these topologies where combinations of the star, 
ring and bus are possible. 

Protocol - the rules by which data communications are controlled. These rules 
are primarily communications standards by which information is transmitted 
and received within and across network boundaries. Protocols include data 
communications procedures and conventions such the as International 
Standards Organization (ISO) seven layered model for communications 
standards and methods of data packet transmission such as farrier Sense 
Multiple Access/Collision Avoidance (CSMA/CA), Collision Detection 
(CSMA/CD) and token passing. 

There exists a variety of LAN technologies from which to choose. Three fundamental network 
technologies with several of their associated characteristics are: 

PBX or Private Branch eXchange - mostly uses in*place twisted-pair wiring, 
can support star or tree topology, and can provide for data, integrated data 
and voice, and facsimile transmission. 

Baseband - uses twisted pair wiring or coaxial cable, will support a star, ring 
or bus topology and can provide for data, voice, and digital facsimile trans- 
mission. 

Broadband - uses coaxial or fiber optic cable, will support a tree or bus type 
topology and can provide for video, voice, data, and security device transmis- 
sion. 

The basic characteristics of our laboratories were 25 to 35 microcomputers in local clusters, a need 
for only data transmission, high data transmission rates, a non-complex installation, and low cost. 
The baseband technology appeared to meet these features most effectively. Some major LAN*s 
which use the baseband technology are Xerox's EtherNet, Datapoint*s ARC, Digital Equipment's 
3Com, IBM's PC Network, Quadram's QuadNet IX, and Corvus's OmniNet. 
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Which LAN? 

The type of microcomputer and LAN configuration was based entirely on the application software 
and laboratory structure. The software and laboratory structure was, in turn, based on the aims 
of the computer literacy courses as determined oy faculty committee consensus. 

Our laboratories, unlike most office environments, involve a large number of people "download- 
ing" the same application software simultaneously. At the end of class sessions there is a large 
queue of tasks at the printers. The Novell system, with its combination token passing, ring-of- 
stars design and system software for handling file-server I/O, fit this requirement very well. 

A token passing protocol is more efficient than CSMA/CA and CSMA/CD with increasing numbers 
of workstations added to the network. On the other hand, token passing, based on a ring struc- 
ture topology, can be a problem. If a node were to fail, the entire network would be halted. Novell 
has worked around this by providing a star-shaped ring design whereby workstations are connected 
in a star fashion via wire centers. System integrity is maintained when a workstation fails or is 
disconnected. 

Also, the NetWare's method of handling file-server I/O enhances system performance under heavy 
load. NetWare's hashing of directories reduces file look-up time, disk caching for often used files 
improves access time, and use of the position of disk head to influence the ordering of disk read/ 
write requests reduces seek times. 

A limited time schedule and budget prevented us from evaluating most major LAN systems. Several 
vendors had announced systems which were not available at the time for demor^-^^ration. While 
we were receptive to a vendor's literature and presentations, we held very dearly to the tenet that 
real-time demonstrations of the network performance with our major software and selected 
workstations was essential. 



With these essential criteria in mind, we selected: 
network: 

Quadram's QuadNet IX 
Novell Advanced NctWare/286 

fileserver: 

NCR PC-8 AT microcomput er (2048 Kb) 
30 Mb Fixed Disk 

workstations: 

Leading Edge Model-D microcomputers (640 Kb) 

STB enhanced graphics cards 

Amdek 722 high resolution color monitors 

• printers,main: 

Okidata 2410's 
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Procurement 

A specification fact sheet 

Wc set up specification sheets for our microcomputer workstations, file servers and for our 
network. A sample specification sheet for the Quadnet IX system is provided in Appendix I. 

Provisions for support: 

The diversity and complexity of current, local area networks require a level of expertise not 
available in many institutions. Ex jerienced help is initially required for consulting and educa- 
tional support. 

An agreement or contract was negotiated for support in the installation and implementation of 
the network with the following areas addressed: 

background and essential conditions of the project 

sco:^e-of-work with specific directions for the consultants. 

consultant's responsibilities (methodology, work schedule, provisions for 
education on network). 

college's responsibilities (access to data, personnel, facilities). 
Ownership of work products (property of the College), 
payment (work accomplished, verification, schedules). 



Several vendors bid on the consulting contract. We were fortunate to have the vendor of the LAN 
system successfully bid on the consulting and education contract. Having the consulting service, 
hardware, and software from the same vendor proved very valuable. This gave us a common access 
to assorted experts and avoided conflicts resulting from vendor quarrels over responsibility for 
problems. 
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Installation 

Hardware and tODologv! 

The major network hardware consisted of file serv- % workstations (microcomputers), cables, 
streaming backup tape and Uninterruptible Power Supplies (UPS*s). An abbreviated listing of 
installed hardware includes: 

network file server 

processor (80286) 
system console (monochrome) 
disk subsystem(s) (30 Mb) 
printer I/O (serial/parallel) 
expanded memory (2 Mb) 
network interface card 
software key card 

Uninterruptible Power Supply (UPS) 

network workstation (PC) 

processor (8088, ipx80 processor family) 
expanded memory (640kb) 
network interface card 

network cables 

type I or type VI (shielded dual twisted pair) 
wire center 

streaming backup tape system (Alloy) 

A star-shaped-ring topology determined the electrical configuration of the laboratory with the 
wire centers acting as "hubs" to the workstation. We contracted out for electrical work in our 
laboratories with our systens engineer overseeing the project. We also provided for support from 
a network consultant in the installation and implementation of the system. Our systems engineer 
was responsible for the major portion of the software installation, system implementation, and 
its maintenance. 

The biggest problem we encountered in the installation was that resulting from the cable 
connections. If cable strands were broken or frayed such that a full wire connection was not made, 
intermittent problems would occur and the network would perform erratically. All connections 
had to be true and firm. Also, we placed all cable into secured conduit or trays so that movement 
or inadvertent bumping would not dislodge it. 

System software 

Systems software was installed by our systems engineer. Consultants were brought in to fine tune 
the network parameters. They also made valuable suggestions on adjusting parameters for our 
custom applications. System software consisted of Nov^jII Advanced NetWare/286 with the 
following features: 

supports up to three parallel and two serial network printers. 

token passing, updates token list for new users automatically. 
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security system with multilevel protection for b'^th users and files. 



memory-to-memory transfer of data. 

allows connection for up to 255 nodes in a "ring-of- stars." 

Menu and security profiles must be established and installed for proper use of the applications 
systems in the student laboratory environment. 



Application software 

For the Fall '87 semester, we had 20 software packages on the LAN's and 3 1 courses formally using 
the laboratories Table 1 provides some information on the kinds of application software used 
by the academic departments. Software applications are categorized as spreadsheet/graphics 
(SSGX database management (DBM), word-processing (WP), business/business games (BBG), 
statistics/graphics (STG), compilcrs/inicirpreters (CI), and communications (COMM). Some 
overlap exists in the specified categories. As an example, several of the software packages listed 
in the spreadsheet category arc template-oriented with direct business applications, '^ther, 
miscellaneous software items are not listed. Major academic departments are Management 
(MGMT); Marketing, Economics, and Fashion Merchandising (MAR/ECO); Accounting and 
Finance (ACT/FIN); and Computer Science and Quantitative Methods (CSC/QM). Each entry in 
the table represents the number of software packages used by category and department. 



Table 1 

Software packages by academic department and catsgory 



ACAi^EMIC DEPARTMENT 

SOFTWARE 

CATEGORY MGMT MAR/ECO ACT/FIN CSC/QM 



SSG 1 1 6 1 

DBM 11 1 

WP 1 1 1 1 

BBG 6 4 1 

STG 1 1 

CI 1 3 

COMM 1 



Data in Tabic 1 does not provide information on the extent of usage of any particular software 
item* We hope to quantify such infornation with the use of a LAN management accounting 
package. From general observation, spreadsheet (LOTUS 1-2-3)1 and word-processing (WS2000)2 
are two of the most used software packages on our systems. 



Implementation 

Training for systems and applications support is crucial for the proper implementation of the LAN 
laboratories. In our agreement with the LAN consultants, we provided for twenty hours of on- 
site educational seminars. These seminars were provided for computer center personnel and key 
faculty in the business and computer science areas. The faculty then held classes for faculty and 
staff end users and for student tutors. 

Problems occurred, but were not so catastrophic. The education and training provided seems to 
have made them more manageable than they might have been otherwise. Education and training 
should be a regularly scheduled exercise. 



Use of the LAN's 



Policies and procedures 

Of critical importance in the use of the LAN*s is the establishment of guidelines and rules. As 
is most often the case, those not technically responsible are less c ^ncerned than computer center 
personnel over security and maintenance time and press for more open access. However, a balance 
must be maintained between security provisions, maintenance time, and open access. 

Thr academic computer center is responsible for the physical inventory, systems, and operations 
support of the LAN*s. The Associate Dean of the School of Business schedules the use of the labs 
and decides which applications arc placed on the systems. In this manner, the academic computer 
center is removed from making decisions on the relative merit of academic applications. 

Each LAN application must have its own set of guidelines. Responsibilities for the administrative 
and technical management of the center should be clearly defined. 



Lotus 1-2-3 is a registered trademark of Lotus Development Corportation, Cambridge, MA. 
WS2000 is a registered trademark MicroPro International Corporation, San Rafael, CA. 
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Usage statistics 

We are preparing to evaluate several accounting packages that can be installed on the LAN's that 
will allow us to keep accurate statistics on usage. We have recorded manually some data on 
laboratory usage by having student operators make head-counts cn a hourly basis in walk-in 
laboratories (WI) and by recording course enrollments for classes regularly scheduled in instruc- 
tional laboratories (IL). While the data is at best **rough*\ it does provide us with an approximate 
measure of usage. All data has been reduced to student-hours per laboratory per semester (Table 
2). Fall and spring semesters are IS weeks in length, summer session is 10 weeks. 



Table 2 



Student-hours usage of LAN laboratories 



Semecter 


Lab 1 (WI) 
28 wkatni 


Buiineii 

Lab 2 (IN) 
28 wkitni 


Computer Science 
Lab 3 (WI) Lab 3 (IN) 
29 wkstni * 


Totals 


Fall '86 


9,831 


10,000 


13,789 


33,620 


Spring *87 


12»dl5 


8,477 


11,676 


33,068 


Summer *87 


3,318 


2,692 


60 


6,060 


Fall 37 


9.291 


7,612 


5,101 12,927 


34,831 



* other workstations (wkstns) are connected to file servers, but not located in the labo. These are not included in lab counts. 
** estimated value based on relative walk-in, instructional lab use. 



Plans for future development 

Use of the LAN*s has stimulated both interest in and use of computers. For the present, we have 
also experienced a decrease in the number of accounts on our host system resulting from a shift 
of basic computer work to the LAN*s. Host system usage, however, is increasing by way of more 
sophisticated applications not available on the microcomputers. Juniors and seniors, without 
structured exposure to the microcomputer laboratories, requested the opportunity to retake a 
computer literacy course under the current regimen. A 200 level course using the LAN's was 
developed for these people. 

Faculty and student usage of the LAN's has increased their productivity in the areas of class 
administration, assignments, research projects, papers, and theses. 
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There is a user demand for enhanced and ada..>!iu^ facilities. Our plans are to: 

• link the three LAN laboratories via fiber optic cable and bridges, 
provide gateways to host processors, 
establish more Iaboratorie.». 



In conclusion, both the users and support people are very satisfied with the general performance 
of our LAN's. This is especially apparent from their requests for more access to the systems 
including office connections to the LAN's. Wc owe the success of these laboratories primarily to 
faculty/staff involvement at the initial stages of course and laboratory design, system-evaluation 
that included site demonstrations, :d adequate provisions for consulting and educational support. 
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Appendix I 



Local Area Network: QuadNET IX 



Marketed by: 



Quadram Corporation 
4357 Park Drive 
Norcross, GA 30093 
(404) 923-6666 

Retail Prices: 

Starter Kit 

Workstation 

Server Station 

Dedicated Server 

Coaxial Cable (per foot) 

Connector (4 Stations) 

Repeater 

Four Station Configuration ... 

Hardware Capabilities: 



Number of Servers 

Number of Workstations 
Server Type 



Memory R- quirements: 



Dedicated Server 

XT Server 

Workstation 



Peripherals Supported: 

Serial Printer 

Parallel Printers 

Plotters 

Hard Disk 

Tape Drive 

Other Mass Storage 

Modems , 

RAM Disks 

Other Communications 
Other , 



Backup Support: 

Vendor Supplied 

Disk 

Global 

Other 



N/A 

$795.00 

$1,495.00 

N/A 

$.95 

$95.00 

N/A 

$9,265.00 



1 

256 

IBM/AT 

[Min/Max] 

256/ 16Mb 
356/640K 
128/640K 



YES 

YES 

YE{^ 

YES 

NO 

NO 

NO 

NO 

NO 

NO 



YES 
YES 
YES 
NO 



Network Description: 



Architecture 

Type 

Speed 

Server Type . 



Security Provided: 

Logon ID 

File Passwords 

File Protection 

Record Protec-'>n 



Diagnostic Supported: 



Cable 

Server 

Workstation 

Network/Station 
Auto ReRoute 



Software Capabilities: 
Operation System: 



Disk Caching 

RAM Disk Support 
Systems Manager .... 
Other 



Token Passing 

Ring/Star 
Baseband 
9.92Mbps 
XT 



YES 
NO 
YES 
YES 



NO 
NO 
NO 
NO 
NO 



PC-DOS 

YES 
NO 
YES 
YES 



Application Software Included: 



Electronic Mail 

Chat 

Utilities 

RAM Disk 

Other 



Print Spooler Features; 



Variable Buffer 

Disk-Based 

Change Paper 

Printer Commands 

Multiple Copies 

Queue Inquiry 

Purge Queue 



YES 

NO 

YES 

NO 

YES 



YES 
YES 
YES 
YES 
YES 
YES 
YES 
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Changing Administrative Database Philosophy; 
Network to Relational 

Becky King 

Baylor University 
Waco, Texas 



This last year was the beginning of a major 
transitional period for Baylor University 
Administrative Computing. Not the least of the changes 
was that of acquiring IBM's relational DB2 as the 
database for all future development* This required a 
complete rethinking of application design and 
integration philosophy because all existing database 
systems employed a CODAS YL network database* This 
paper discusses the background and implications of this 
major software change as well as lessons learned 
through the first ye^r of implementation of SQL--based 
relational systems . 
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Changing Administrative Database Philosophy; 
Network to Relational 



Baylor University, located in Waco, Texas, is the oldest 
university in continuing existence in Texas* The 
approximately 11,500 students are spread throughout the 
College of Arts and Sciences and the Schools of Business, 
Education, Law, Music, and Graduate Studies in Waco and the 
School of Nursing in Dallas* There are also affiliated 
graduate programs with the U.S. Army Academy of Health 
Sciences in San Antonio* Baylor is under the patronage and 
general direction of the Baptist General Convention of Texas 
and its mission^ as stated by President Herbert H. Reynolds, 
is "to be an institution of higher learning where education 
may be gained under Christian influences and ideals"* Dr. 
Reynolds has defined several major goals for the late 
twentieth century, one of which is ..o "achieve a state of 
computer literacy within the faculty and student body"* This 
charge from the top influences all systems development and 
implementation* It lends support to the effort to integrate 
and enhance the entiro database of University information. 



Baylor Computing Environment 

The Center for Computing and Information Systems, under 
the leadership of the Director of Information Systems, is 
composed of the Academic Computing Section, the Administrative 
Computing Section, the Communications Section, the Office 
Automation Section, and the Microcomputer Store* The 
Administrative Section includes two associate directors, two 
systems programmers, a database programming coordinator, four 
programmer /analysts, four student programmers, and a 
microcomputer support person as well as operations and 
production services personnel. Administrative computing has 
been handled by a Honeywell computer since 1968. Through 
several hardware upgrades the University has been well-served 
by this environment, developing many inhouse systems iiicluding 
a respected on-line registration system. Several years ago a 
commitment to the database philosophy for new software 
development was made, and implementation of Human Resources 
and Alumni /Development Systems followed using Honeywell's IDS- 
II network database management system. Hovzever, as the 
educationc.1 arena oecame more competitive, the funding for new 
staff tightened, the demands of more computer-literate clients 
multiplied, and the number of third party oOfcware packages 
available increased dramatically, the administration became 
convinced it was time to re-examine the administrative 
computing situation and the philosophy of developing all 
software inhouse. 
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After much study and work by various appointed committees 
composed of faculty and staff, several major hardware and 
software decisions were made in 1986 by the adminiscration and 
Board cf Trustees. An IBM 4381 was purchcsed and MVS/XA was 
chosen as the operating system. The VSAM version of 
Information Associates' Student Information System was also 
purchased and implementation begun. The Computer Associates 
Unicenter software support products were acquired. And 
finally, IBM's relational DB2 was chosen as the databc se to be 
used for cTll major system development. These critical 
decisions forced the Administrative Section into a difficult 
conversion situation. The influx of new products also 
compelled i-ho staff to learn many new tools and concepts while 
continuing support of current Honeywell syrtems. HowWer, 
everyone involved, while sobered by the work ahead, believes 
the results will put Baylor in position to become a leader in 
university administrative computing. 



DBMS Decision 

In considering the database selection, we remained 
committed to the database approach to systems development. 
Our current database systems are successes, and we are sold on 
the integration of data and the tools that come with a DLMS . 
Because the lA Student Information System had been chosen, we 
were primarily looking at databaso management systems 
compatible with that software. At the time lA had versions 
running under ADABASE, IDMS, and VSAM on the IBM, but we 
l^earned of plans to introduce an SQL version in the future. 
I'll is information, along with some questions about the current 
lA database versions of the SIS software, led us to look very 
carefully at DB2 and ultimately select it. Som.. of the major 
reasons for this decision were: 

- We were attracted to the relational technology for its 
flexibility. The ability to add elements to tables and 
define new tables and indexes fairly simply was a very big 
plus. Also, we felt system development in general would 
be a faster process with a relational DBMS. 

- Relational systems are the easiest to understand. The 
terminology is simple. Clients can more easily grasp the 
concepts of tables, rows, and columns than records and 
sets . 

- SQL is becoming a standard. Many vendor software products 
now have SQL versions. Therefore, any tools we might want 
to purchase in the future would be available. 

- Finally, IBM is touting DB2 as its database of the future. 
And DB2 has been well received by critics that rarely laud 
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IBM undertakings. This reinforced our feelings that most 
products available in the future will work with DB2. 
Also, we liked having the same vendor for hardware and 
software . 



Implementing Relational Technology 

After our DBMS wai chosen, we had to decide what to do 
with it. What would be our first DB2 application? We 
selected the Student Payroll System, a relatively small system 
with a limited group of primary users . The current system was 
a completely batch one written in COBOL-68 which caused 
headaches each month for all involved with it. The programs 
had been patched for years and produced inconsistent and 
unpredictable results. And because it had to interface with 
the newly purchased Student Information System, Student 
Payroll would need to be one of the first systems converted to 
the IBM anyway. So not only did we have a smaller system on 
which to learn about DB2, but we could also improve our 
service to the student body by rewriting a poor system which 
impacted many of them. 

We then began reading manuals - many, many manuals. We 
invested in two IBM DB2 classes, one on database 
administration and one on system administration. These were 
especially helpful in learning DB2 temninology and design 
techniques for improved performance. Because SQL is so simple 
to learn and because our programmer/analysts were already 
familiar with a much more compj.ex data manipulation language 
(DML) , we decided against programming classes for the staff. 
We have been happy with this decision. Our people have picked 
up SQL and its use with COBOL very quickly. 

Designing the Student Payroll relational database was a 
new and exciting task. Th^ major process was defining all the 
data elements and normalizing them into tables. The resultant 
database has nine tables and nine indexes. The student l.D. 
number is repeated in all but one tabl3 and the student 
account number is repeated in several. This repetition of key 
fields without referential integrity in place is a troubling 
aspect of relational design in DB2. However, the design 
process itself is greatly simplified by having to consider 
only one data iJtructure. In our database, after consultation 
with IBM and other DB2 users, we chose to define one table per 
tablespace and to do our own VSAM management rather than let 
DB2 handle it through its storage groups. The consensus 
seemed to be that tb/ese two choices were the most efficient 
and provided us the most control . 

COBOL programming in SQL, while fairly simp]e to master, 
did require some adjustments and initial study. The major 
differences we have found include: 
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- Rather than accessing the information a record at a time 
within a program, a "set" of data is retrieved based on 
the SQL requiremr ^ts coded. Than a cursor is used to 
fetch succeeding rows from this "set". But because a 
knowledge of record and set structures is not necej^sary, 
our staff found this much easier to use than the CODASYL 
DML. For example, the FIND statmentin IDS-II has eight 
very different formats to be used depending on how the 
data is to be accessed. 

- The size of the source listing is tremendously increased 
Ly the lines generated by SQL includes and calls. This 
makes the listing harder to read. 

- To be made ready to execute, an SQL program must be run 
through two additional steps. Before the compile, a DB2 
precompile must be done. This phase does some editing of 
SQL statmenrs and produces a database request module. The 
second additional 3tep is the bind step which produces an 
application plan used to allocate DB2 resources and 
support SQL requests during execution. Therefore the 
process of creating an executable module takes somewhat 
longer than with non-DB2 programs. 

- Within an SQL statement field names cannot be referenced 
which are part of copy members to be copied into the 
program. These fields are not copied into the source 
until the compile step. Therefore, when the precompiler is 
verifying the SQL syntax, those field names are undefined 
and result in error condition codes. 

- Special programiring considerations are required in our 
network system when enlarging variable length fields. If 
a modify return code indicates there was not enough room 
on the page for the extra data, the record containing the 
field must be deleted and re-added by the program. In 
DB2, the system will move the enlarged row to the nearest 
page with sufficient free space and set up a pointer in 
the old position. This simplifies programming but does 
not relieve the need for periodic data reorganizations. 

The design and programming on the new Student Payroll 
System went very well. It consists of 23 batch procj^^ams and 
22 CICS programs. We had originally planned to go ''live" with 
the first payroll of the fall semester. However, we switched 
over to the lA SIS in September and had to use all available 
manpower on tasks supporting this critical project for much of 
the past several months, thus delaying the Student Payroll 
implementation. Also, balancing reports from the new and old 
systems has been an even greater job than anticipated because 
of a multitude of program and data inaccuracies in 'he old 
system. We did not truly realize how badly we needed this 
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conversion. We have been running parallel systems since mid- 
October and expect to discontinue the old system in December. 
Our clients .using the new programs in running the parallels 
are enthusiastic and anxious for the changeover. 

Relational/Network Contrasts 

The experience on this first DB2 system has taught us a 
great deal about differences between the network DBMS that we 
have been using for several years and the new relational DBMS . 
Much re-thinking of the whole date oase design and definition 
process has been required. Major points in our comparison of 
the two types of DBMSs include: 

- In a network system, information about the data is coded 
into the structure through the sets . Database navigation 
is more complex because a knowledge of the set names, 
structures, and order of storage is required. Also, the 
programmer must be aware of record, set, and roalm 
currencies in all data manipulations. The relational 
structure is easy to understand - tables as opposed to 
records and sets. And navigation is strictly oy field 
values. It does, however, require extra columns in the 
tables to provide the links implied in the network 
structure. 

- A relational system is much more flexible than its network 
counterpart. New tables are easily added to a relational 
database as are new fields to existing tables. Indexes 
can be createa and dropped as needed. These updates 
affect only the application programs that reference the 
changed or added objects. Usually a restructure is needed 
to odd new fields, -ecords, and sets to a network 
database. 

- As relationships between entities change, these changes 
are easily defined based on the data in a relational 
system. In a network database, a restructure is required 
to define new set structures for these additional 
relationships . 

- In a relational system, a user can be given a logical 
window into a database through a view and can even become 
his own DBA and define further views. 

- SQL is a high level language used by the DBA, programmer, 
and user. It includes built-in functions like SUM, ORDER 
BY, COUNT, and AVG which are not available in the CODASYL 
DML. The consistency of using the same easy-to-understand 
language to define and manipulate data is an advantage 
over network .systems . 
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- We can now, with our relational system, access tables from 
more than one database in a single application program. 
This is a limitation of our CODASYL environment that 
requires us to use calls to other executable modules to 
access more than one database. 

- DB2 security is more extensive than that in our network 
system. Using SQL commands, privileges can be granted and 
revoked a.s required. Through the use of views, this 
access can reach down to the field level and be based on 
field content. Also, privilege must be granted to execute 
database utility and administration functions. Our 
network system allows the use of subschemas to limit views 
of the data but subschemas are very cumbersome and do not 
provide the granularity of security found in DB2 . 

- The consistency and integrity of data across tables has to 
be maintained by the appli ration programs in DB2. There 
is no referential integrity. In a network database, some 
of this integrity can be handled by the set structure. 

- Whether or not an index is used to access data is 
determined internally by DB2 rather than explicitly stated 
by the programmer as in a CODASYL environment. This 
requires that SQL statements be formulated correctly if 
use of an index is desirable. 



Future Administrative Computing Plans 

The Administrative Computing Section has a tremendous 
amount of work ahead that must be done as quickly and 
efficiently as possible but not without much thought anJ 
planning. We have established the policy that all inhouse 
development will be done in DB2. We have begun design work on 
conversion of our IDS-II Human Resources system to DI32 , 
Included in this process will be some important enhancements 
that our clients have requested such as an applicants 
subsystem. And we are spending time in analyzing how we can 
make this new system more helpful to the University's 
executive level. This will be a major thrust of all our 
future development - to support our decision makers with 
relevant, timely information in useful formats. Two 
committees coiaposed of a cross section of members from across 
campus are winding up studies of potential Financial 
Information Systems and Alumni /Development Systems. The 
committees' recommendations and the University's decisions in 
these two areas will help decide the direction of our work 
effort in the next two years. A primary consideration in 
evaluations of vendors' software will be present or future 
availability of SQL versions. We are facing a very 
challenging timo. A relational database system like DB2 gives 
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us a more flexible, easier to use tool than we have had in the 
past to aid in accomplishing the tasks before us. As Dr. 
Reynolds stated in the November 1987 issue of Cause/Ef feet , 
'•Our plan is to literally try to have the most up-to-date 
information systems that we possibly can, to lead our people 
where they have not been before, or where they have not even 
anticipated going." Administrative computing will be a major 
factor in this information revolution and in the continued 
striving to better serve Baylor's students, employees, and 
friends . 
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